Received: (at 9088) by debbugs.gnu.org; 26 Dec 2013 14:48:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 26 09:48:00 2013
Received: from localhost ([127.0.0.1]:43123 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VwCEC-0006lX-6E
for submit <at> debbugs.gnu.org; Thu, 26 Dec 2013 09:48:00 -0500
Received: from mail-ea0-f178.google.com ([209.85.215.178]:54573)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <stefano.lattarini@HIDDEN>)
id 1VwCE7-0006ko-58; Thu, 26 Dec 2013 09:47:55 -0500
Received: by mail-ea0-f178.google.com with SMTP id d10so3800119eaj.9
for <multiple recipients>; Thu, 26 Dec 2013 06:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:mime-version:to:cc:subject:content-type;
bh=xV+tF5V0zXLahAcwHaRdnTkmKUYdvtDOoZ0Pb2z08bw=;
b=BdITuCjiPu5pFClAzH1nCylckNXuI3NyBQG3ZEJ8+vu2iE+VlIRpi2nQKOagFsx5TK
w0O43oZI5GybwPXPw6c34P5iv6mcxk3uZABfI4hGGCvw6rVmpDv0NdgLdiJSRKp1/89b
JAaT+dJPjIl8WpLBzuJFrAf3M/FA2RuYjLnvP5uud0RjHPmeHDyOqU6WlcqC8SRGYHT5
VybNfj7U8KRyPuVUIv70pqJrmcaHI0rPnkSEWRS6rhkNSAxjsl3cvbFW4v8+N9cABuRV
zIN7HnQhMtssLHiZOXpgJ97tSXN7FLH728Wc5tzn1RvqWqIdegfRNwjvdBuXwSh7URAx
/fWA==
X-Received: by 10.15.54.130 with SMTP id t2mr8087137eew.72.1388069274024;
Thu, 26 Dec 2013 06:47:54 -0800 (PST)
Received: from [192.168.0.101]
(host143-4-dynamic.5-87-r.retail.telecomitalia.it. [87.5.4.143])
by mx.google.com with ESMTPSA id p45sm73396918eeg.1.2013.12.26.06.47.51
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 26 Dec 2013 06:47:52 -0800 (PST)
Message-ID: <52BC4195.7010307@HIDDEN>
Date: Thu, 26 Dec 2013 15:47:49 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: "automake-patches@HIDDEN" <automake-patches@HIDDEN>
Subject: [PATCH] Make clear the JAVA primary will no longer be developed,
not even for bug fixes.
Content-Type: multipart/mixed; boundary="------------080106010309000601090700"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 9088
Cc: 8540 <at> debbugs.gnu.org,
=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?= <betelgeuse@HIDDEN>,
tsuna <tsunanet@HIDDEN>, Stefano Lattarini <stefano.lattarini@HIDDEN>,
9088 <at> debbugs.gnu.org, 8662 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
This is a multi-part message in MIME format.
--------------080106010309000601090700
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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
--------------080106010309000601090700
Content-Type: text/x-patch;
name="0001-docs-make-clear-the-JAVA-primary-is-frozen.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0001-docs-make-clear-the-JAVA-primary-is-frozen.patch"
From 50a08a2bc300d600603cdb5b5756baf71b9b431a Mon Sep 17 00:00:00 2001
Message-Id: <50a08a2bc300d600603cdb5b5756baf71b9b431a.1388069253.git.stefano.lattarini@HIDDEN>
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Date: Thu, 26 Dec 2013 15:46:13 +0100
Subject: [PATCH] docs: make clear the JAVA primary is frozen
* doc/automake.texi: Here. The JAVA primary is broken in several ways,
and will no longer be developed, not even for bug fixes.
See also automake bugs #9088, #8662 and #8540.
Signed-off-by: Stefano Lattarini <stefano.lattarini@HIDDEN>
---
doc/automake.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/automake.texi b/doc/automake.texi
index 91b4a0a..6d90182 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7598,7 +7598,9 @@ native machine code; @pxref{Java Support with gcj}). Note however that
Future Automake releases will strive to provide a better and cleaner
interface, which however @emph{won't be backward-compatible}; the present
interface will probably be removed altogether some time after the
-introduction of the new interface (if that ever materializes).
+introduction of the new interface (if that ever materializes). In any
+case, the current @code{JAVA} primary features are frozen and will no
+longer be developed, not even to take bug fixes.
Any @file{.java} files listed in a @code{_JAVA} variable will be
compiled with @code{JAVAC} at build time. By default, @file{.java}
--
1.8.5.rc0.335.g7794a68
--------------080106010309000601090700--
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 20 May 2013 00:07:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 19 20:07:08 2013
Received: from localhost ([127.0.0.1]:52006 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UeDd6-0005hA-8M
for submit <at> debbugs.gnu.org; Sun, 19 May 2013 20:07:08 -0400
Received: from mail-pa0-f41.google.com ([209.85.220.41]:51931)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <notzed@HIDDEN>) id 1UeDd3-0005gZ-UN
for 9088 <at> debbugs.gnu.org; Sun, 19 May 2013 20:07:06 -0400
Received: by mail-pa0-f41.google.com with SMTP id rl6so5152464pac.0
for <9088 <at> debbugs.gnu.org>; Sun, 19 May 2013 17:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:cc
:subject:references:in-reply-to:x-enigmail-version:content-type;
bh=Su+eiW6Ln2YBLU1+5L7WXSP8+0vB+LNkeiZlW75Q95s=;
b=A/GBd7TuOLtZVP4tAIGt+tGf3AE3KkhvtvJIMAIyiAdsb+AEbWdCreZlBrgfyKJMpt
3u+CZNsIb6/PQTFZZIxJxv72paBoCpiDwWMsBB+TIUXaM8+NrSysXdplbMLsRC60/B3u
9OgMFcJ6BUuHkBO72Ixrt/rtbrugjo67yFnb7ryeg/thrUMf+6Z+um4szLV3rxpBL+zJ
O+XLyrhDg3eVQgREPekLeZMknOE5PdKcxdF5WrARUhTlymm73qLqTf0EDPlkHPao833B
vq//dh6MJ+TQWSinx72AtCtRTJ2fXFiJgFxP68MoEnLMtjQU+ARhRu1NtvKtDwAjMp8s
7udQ==
X-Received: by 10.68.105.164 with SMTP id gn4mr57715678pbb.42.1369008390114;
Sun, 19 May 2013 17:06:30 -0700 (PDT)
Received: from [192.168.1.7] (ppp118-210-177-43.lns20.adl6.internode.on.net.
[118.210.177.43]) by mx.google.com with ESMTPSA id
ze11sm22967719pab.22.2013.05.19.17.06.27 for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Sun, 19 May 2013 17:06:29 -0700 (PDT)
Message-ID: <51996901.3060902@HIDDEN>
Date: Mon, 20 May 2013 09:36:25 +0930
From: Michael Zucchi <notzed@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: bug#9088: the jar fragment
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN>
<51945929.3090007@HIDDEN> <5194B075.6060801@HIDDEN>
<5196CBB6.90401@HIDDEN>
In-Reply-To: <5196CBB6.90401@HIDDEN>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/mixed; boundary="------------090100020701010306040504"
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
This is a multi-part message in MIME format.
--------------090100020701010306040504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Forgot the attachment.
--------------090100020701010306040504
Content-Type: text/plain;
name="Auto6.mak"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Auto6.mak"
# 'simulate' automake environment
jardir = $(datadir)/java
srcdir=../maktest
MKDIR_P=mkdir -p
VPATH=.:$(srcdir)
all: foo.jar
##
## The makefile.am `equivalent' stuff
##
## This user has chosen to make it gnu-make only.
##
jar_JARS=foo.jar
# sources, all relative to '.'
foo_jar_SOURCES = $(shell cd $(srcdir) ; find src -name '*.java')
# 'generated' sources
foo_jar_SOURCES += stuff.java
# resources all relative to '.'
foo_jar_RESOURCES_PREFIX = src res
foo_jar_RESOURCES = $(shell cd $(srcdir) ; find src res -name '*.txt' -o -name '*.jpg' )
# 'generated' resources
foo_jar_RESOURCES += a.txt b.txt c.txt
foo_jar_MANIFEST = manifest
foo_jar_MAIN = au.notzed.stuff.Main
# build classpath
foo_jar_LIBADD = lib/jjmpeg.jar lib/test.jar
# "custom" targets
a.txt b.txt c.txt:
touch $@
stuff.java:
echo "class stuff { }" > stuff.java
##
## the jars.am fragment for foo.jar
##
# windows needs ;, of course ...
# automake.in generates this from LIBADD?
foo_jar_CLASSPATH=lib/jjmpeg.jar:lib/test.jar
foo_jar.stamp: $(foo_jar_SOURCES) $(foo_jar_LIBADD)
rm -rf build/classes/foo_jar
$(MKDIR_P) build/classes/foo_jar
clist=""; \
slist='$(foo_jar_SOURCES)' ; \
for n in $$slist ; do \
if test -f $$n ; then \
clist="$$clist $$n" ; \
else \
clist="$$clist $(srcdir)/$$n" ; \
fi ; \
done; \
echo compiling: $$clist; \
javac -cp $(foo_jar_CLASSPATH) -d build/classes/foo_jar $$clist
touch $@
# the complexity here is due to
# a) having to walk the 'VPATH' manually
# b) having to remap the relative roots of resources to the jar file root
# c) portable shell & tools
foo.jar: foo_jar.stamp $(foo_jar_RESOURCES) $(foo_jar_MANIFEST)
rlist='$(foo_jar_RESOURCES)'; \
clist=""; \
for n in $$rlist ; do \
found=0; \
for p in $(foo_jar_RESOURCES_PREFIX) ; do \
t=`echo $$n | sed "s@^$$p/@@"` ; \
if test $$t != $$n ; then \
if test -f $$n ; then \
clist="$$clist -C $$p $$t" ; \
else \
clist="$$clist -C $(srcdir)/$$p $$t" ; \
fi ;\
found=1 ; \
break ; \
fi ; \
done ; \
if test $$found -eq 0 ; then \
if test -f $$n ; then \
clist="$$clist $$n" ; \
else \
clist="$$clist $(srcdir)/$$n" ; \
fi ;\
fi ; \
done ; \
flags="cf" ; \
files="$@" ; \
if test -n "$(foo_jar_MANIFEST)" ; then \
flags="$${flags}m"; \
if test -f "$(foo_jar_MANIFEST)" ; then \
files="$$files $(foo_jar_MANIFEST)" ; \
else \
files="$$files $(srcdir)/$(foo_jar_MANIFEST)" ; \
fi; \
fi ; \
if test -n "$(foo_jar_MAIN)" ; then \
flags="$${flags}e" ;\
files="$$files $(foo_jar_MAIN)" ; \
fi; \
echo "jar $$flags $$files $$clist" ; \
jar $$flags $$files -C build/classes/foo_jar . $$clist || ( rv=$$?; rm -f $@ ; exit $$rv )
--------------090100020701010306040504--
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 18 May 2013 09:13:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 18 05:13:54 2013
Received: from localhost ([127.0.0.1]:49953 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UddD7-0002y1-2J
for submit <at> debbugs.gnu.org; Sat, 18 May 2013 05:13:54 -0400
Received: from mail-ee0-f53.google.com ([74.125.83.53]:36051)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1UddD2-0002xY-WC
for 9088 <at> debbugs.gnu.org; Sat, 18 May 2013 05:13:51 -0400
Received: by mail-ee0-f53.google.com with SMTP id c1so2588877eek.26
for <9088 <at> debbugs.gnu.org>; Sat, 18 May 2013 02:13:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=RVN45JZuEiHBo6GCLYmVgQ9QsDzNDs2sb9NYZf/31hs=;
b=T5q23ZwggjoYIRKMvG6Fx5S+bYo6NuwiyGrAPztDpOwPQC2tS6OS5b8ZxbgqfEiiOp
wIMkXDAeMwGz2qpSRGOJmXVg4Kle+ekxWoNySz+eDp6C/zb2i1vo/vixvvwpKSXj9pjx
OAQk7o729pTA0ATZavGDKFw5G5V6h+Fh3bdC0KUwnJdxpQcWUS2YAIDBNLcXtF5gPovJ
7yp+6aVH8UzHf5JnMpSKajhGBxyq4MJitrK+3wJX9HKKy63iNRrTUMvUkSi1iKcpjmiI
PCkuVIg7204jfW2CYthdBs0VoXe/fhz1ytAkPDz7G+U5GhBYRdPZ3WnolW4SHyEU6nJY
7UkQ==
X-Received: by 10.14.111.129 with SMTP id w1mr139355661eeg.13.1368868402537;
Sat, 18 May 2013 02:13:22 -0700 (PDT)
Received: from [192.168.178.20]
(host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93])
by mx.google.com with ESMTPSA id
bn53sm24678560eeb.7.2013.05.18.02.13.20 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 18 May 2013 02:13:21 -0700 (PDT)
Message-ID: <51974629.2010802@HIDDEN>
Date: Sat, 18 May 2013 11:13:13 +0200
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Michael Zucchi <notzed@HIDDEN>
Subject: Re: bug#9088: Java, JARS primary?
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN>
<51945929.3090007@HIDDEN> <5194B075.6060801@HIDDEN>
<5195A919.9080603@HIDDEN>
In-Reply-To: <5195A919.9080603@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
On 05/17/2013 05:50 AM, Michael Zucchi wrote:
> On 16/05/13 19:39, Stefano Lattarini wrote:
>> On 05/16/2013 05:57 AM, Michael Zucchi wrote:
>>> On 15/05/13 22:39, Stefano Lattarini wrote:
>>>> On 05/15/2013 01:52 PM, Michael Zucchi wrote:
>>>>> On 14/05/13 03:47, Stefano Lattarini wrote:
>>>>>
>>> Well if that's a requirement, then it just has to be added right? It's
>>> not impossible, it's only software ...
>>>
>> I failed to parse this. Can you rephrase?
>
> It means the problem is an economic one, not a technical one.
>
> It's a mostly facetious saying coined by a fellow work-mate which
> basically means 'we can do whatever you want (but it will cost you)'.
>
> Or broken down logically, the technical problem:
>
> a) We are solving a problem.
> b) We are using a general purpose computer to solve it.
> c) Any problem can be solved by a general purpose computer.
> d) Therefore, we can solve any problem.
>
> (where of course, problem is a computer related problem, which this
> clearly is)
>
> Here the cost is time that could be spent elsewhere, and maybe some
> lost/grey hairs.
>
>>>> Doing too much pre-processing in automake.in (that is, at Automake time)
>>>> would prevent us from being able to grasp GNU make specific stuff. So
>>>> let's try to keep such pre-processing at a minimum.
>>>
>>> I'm only talking about iterating a list of strings and printing them in
>>> various ways, i'm pretty sure it does that kind of thing already.
>>>
>> Yes, but the price is reduce flexibility at Automake time. Which might
>> be irrelevant or very important, depending on the expected usage patterns
>> of a feature.
>
> I'm lost here. You seem to be talking about something I haven't even
> written yet.
>
My point was that, if you need to parse and analyze the content of a
make variable (let's call it FOO) at automake runtime rather than at
make runtime, the contents of that variable will have to be rather
"static"; that is, you lose at least two abilities:
1. Even if you just assume your users will use GNU make, you won't
be able to employ GNU make specific functions in the definition
of FOO, because automake doesn't grasp them anyway.
2. Your users will likely not be able to override that variable
at make runtime (which might be nice for debugging or testing
purpose).
Now, depending on the situation, the intended uses for a feature, etc.,
the loss of those two abilities can either be irrelevant, merely annoying,
or tragic.
> [SNIP]
>>> My initial version listed every file, and used the gnu-make specific
>>> extensions in order to make it not "totally suck". But then I ran into
>>> problems with how to handle resources and rather than work on solving
>>> those in a way which could fit into an automake.am fragment, I thought
>>> i'd try the approach I had desired from the start.
>>>
>> Given my ignorance of Java, I'm fully ready to change my mind on
>> this; but then I need examples that are much more clear, complete,
>> self-explanatory and *working*. I think you should start perusing
>> the java tests in the 't/' subdirectory of the Automake source tree,
>> and start writing similar tests that show how you envision your
>> feature to work in different scenarios. At this stage, using GNU
>> make specific constructs is OK; I promise I won't bother you about
>> them anymore.
>
> Well the makefile works as much as it was designed to.
>
What I mean is that I'd like to have a test script in 't/', say
't/java-new.sh', that demonstrate how your features work, and that
I can run with a simple "make check TESTS=t/java-new". That kind
of automation is going great lengths toward making me more willing
to try out your code, think about possible problems, and clarify my
doubts (hopefully).
> I don't really understand how the unit tests work.
>
You can try starting from an existing test, and modify it as fit. If
you have doubts, take a look at the 't/README' file. If you get stuck,
just ask here for help.
> It's a bit frustrating trying to make you enough of a java build expert
> in a handful of emails when i'm not one myself. Perhaps it's just a lot
> simpler than you expect - it has far fewer complexities than
> cross-platform c libraries.
>
I sincerely hope so ;-) I think most of the issues here are just due to
newbie misunderstanding on my part. Just be patient.
>>> This particular target was all very simple until i added the LIBADD
>>> dependencies which meant i could no longer just use $^ as i had.
>>>
>>> I couldn't think of a way of having $^ just list .java files whilst
>>> still depending on the LIBADD stuff for running the compiler but if that
>>> was possible the problem would vanish.
>>>
>> Consider that $^ is not portable to all non-GNU makes, IIRC (but I'm not
>> 100% sure of this, I'll have to double check), so that we'd likely still
>> need to rewrite such idioms when we make the transition from your
>> prototype from the final implementation. Not a big deal right now, but
>> something worth keeping in mind.
>
> Really?
>
Eh, I'm not really sure. I know for a fact that '$<' is not portable when
used outside an inference rule (and that limitation is compliant with POSIX).
As for $^, I'd have to double-check on real-world make implementations, but
I hold no great hopes, given that it's not even named in POSIX:
<http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html>
> Bummer. How does one get the list of requirements then, or is
> make pretty much hard-coded for C with a single source file using $<?
>
No, you can't even use '$<' in non-inference rules. You just have to
explicitly spell out your deps in the recipe.
> Is $? portable?
>
Yes (see link above to POSIX spec).
> This is what java.am uses. Not that it's any use here.
>
Indeed.
> Obviously it can just use the variables instead, but it then needs to
> handle srcdir manually.
>
There are several Automake-generated rules that do so already (see e.g.,
lib/am/yacc.am); so that wouldn't be something new (sadly).
>>> Actually the end result I need explicitly for jar is this:
>>>
>>> -C $(srcdir)/src a/a.txt \
>>> -C $(srcdir)/src b/b.txt \
>>> -C $(srcdir)/res c/c.txt
>>>
>> But how can the code know, in general, to only strip the first component
>> of the resources file? That is, why:
>>
>> -C res c/c.txt
>>
>> and not
>>
>> -C src/c c.txt
>>
>> ?
>>
>> And it gets worse; if you have a resource in a/b/c/d/foo.txt, which one
>> of these possibilities should be used:
>>
>> -C . a/b/c/foo.txt
>> -C a b/c/foo.txt
>> -C a/b c/foo.txt
>> -C a/b/c foo.txt
>>
>> ?
>
> Oh he finally gets it!!!
>
(BTW, this comes across as a little disparaging. Which is strange, given
your polite tone so far. So I'll assume you weren't being sarcastic here,
and it's just a "language fail" on my part).
> Yes, this is the problem that needs solving. Which is why EXTRA_DIST's
> mechanism isn't any use, etc, and so on.
>
> I'm sorry i took so long to enunciate it but i thought 'relative root'
> was fairly obvious. Have you never used zip or tar?
>
Of course, but I was missing some context here. Now my understanding is
roughly this:
- Placement of *.class files in a precise point of a directory layout
is extremely important in the Java world.
- There is an API that allow simple access from Java objects to data
files ("Resources", in Java lingo). For that to work properly, the
accessed data file must be in the same directory of the *.class file
containing the class of the object that is accessing the data.
- All of the above remains valid when the directory structure is
"embedded" in a Jar file.
Please correct me if I'm still harboring some misunderstanding.
> Your name suggests there may simply be a language barrier here.
>
The language barrier being referred more to the Java language rather
than the English language, though ;-)
>>> b.2)
>>> foo_bar_RESOURCESDIRS = src res
>>>
>> (or foo_bar_RESOURCE_PREFIXES even)
>>
>>> foo_bar_RESOURCES = src/a/a.txt src/b/b.txt root/c/c.txt
>>>
>>> (use regex/sed to strip either root: it can be safely assumed they are
>>> independent trees so this should be easy)
>>>
>> This sounds the best approach so far. I'd love to see a preliminary
>> implementation of that ;-)
>
> Ok. This the one that seems the most simple to implement too.
>
> When I have something I will return.
>
OK, thanks.
>> I fear HACKING is quite incomplete in this regard; the best reference
>> for what can and can't be done portably with POSIX tools in the
>> Autconf manual, section 11 "Portable Shell Programming":
>
> Ok thanks.
>
>>> Even if
>>> every file was listed by hand these capabilities are still going to be
>>> required.
>>>
>>> I notice that automake tends to just use `` instead:
>>>
>> What do you intend with `` exactly? Are you referring to command
>> substitutions? If yes, how are they related to command line limits
>> issues.
>
> What i was talking about was putting the command line arguments in a
> file, vs putting the command line arguments in a variable.
>
> automake tends to use variables.
>
The question here is more subtle than it seems. I lack the skills to
clearly explain it in a short time, but maybe the comments below can
help to shed some light on the issue. If not, I'll try to give a more
complete explanation. Just let me know.
> e.g. as a file (a toy example, i know it's wrong)
>
> some.jar: $(SRCS)
> rm -f srcs
> for n in $(SRCS) ; do \
>
But if the content of $(SRCS) is too long, the command line of the shell
invoked by make would already been exceeded here, before any command
line length for a java process invoked by the shell can be exceeded. In
fact, the shell wouldn't even get to run, because the 'exec' system call
invoked by make to launch the '/bin/sh' process would fail with an
"Argument list too long" error.
> echo $n | sed 's|^|$(srcdir)|' >> srcs ; \
> done
> javac @srcs
> rm -f srcs
>
> (the "@srcs" reads the arguments from the file)
>
> vs
> (more or less how java.am does it)
>
> some.jar: $(SRCS)
> list1='$(SRCS); list2="" ; for n in $$list1 ; do \
> entry=`echo $n | sed 's|^|$(srcdir)|'` ; \
> list2="$$list2 $$n" ; \
> done ; \
> javac $$list2
>
> And as to how they're related to command line limits? `everything
> inside is a command line is it not`?
>
Not necessarily. That is a command substitution, so, AFAIK, the shell
will simply fork to execute it, without any need to call 'exec'. So no
command line length can be exceeded. Example on my Debian machine:
$ long_line=$(python -c 'print ": "*10000000') # Create long dummy cmdline
$ echo ${#long_line} # Verify it's very long indeed
20000000
$ bash -c "$long_line" # Too long to be run by the shell.
bash: /bin/bash: Argument list too long
$ var=`$long_line` # But not too long to be used in a command substitution
$ echo ${var+set}
set
> Every rule action is a command line?
>
Basically, yes. For example, if we have:
foo:
echo 1
echo 2.1; \
echo 2.2
echo 3
then to build 'foo' make will run three command lines:
echo 1
echo 2.1; echo 2.2
echo 3
>>> aren't command line
>>> limits a portability issue anymore, or is it just not likely a problem
>>> with c source?
>>>
>> Mostly, it's *extremely* difficult to exceed command line length limits
>> with a list of sources, unless you are going to build a program or
>> library (or Jar file, in our case) that has thousands of sources ...
>
> Ok i'll just ignore it at this point.
>
Good choice IMO.
Regards,
Stefano
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 18 May 2013 00:31:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 17 20:31:17 2013
Received: from localhost ([127.0.0.1]:49660 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UdV3N-00073E-9f
for submit <at> debbugs.gnu.org; Fri, 17 May 2013 20:31:17 -0400
Received: from mail-pd0-f180.google.com ([209.85.192.180]:52244)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <notzed@HIDDEN>) id 1UdV3L-00072s-3K
for 9088 <at> debbugs.gnu.org; Fri, 17 May 2013 20:31:16 -0400
Received: by mail-pd0-f180.google.com with SMTP id 10so2698117pdc.25
for <9088 <at> debbugs.gnu.org>; Fri, 17 May 2013 17:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:cc
:subject:references:in-reply-to:x-enigmail-version:content-type
:content-transfer-encoding;
bh=qo3oOfzr3dbQlv1RmgLLJV/Xn8vNZ1WoW8AjvTB0LAU=;
b=gVzrmaDfvNVqP9u1/LlnUxA3wKVHuRV6/asWldq8yBDl9FvwHblaSSxi9bfbvDxjfy
/lQrgGqlj19bCW67q+tIRZJF8rYJuaSMrmF2rSGwj9ACwlzzSefMDHCSnjj+s725BW7g
/CC9BqoB/oxRyG+REwv588kGOhVyi0A47rI3YVorYriX1XlSQri13hBi+W08BjQDNgUK
vQftgyhJZGflb0kRNI66dBv7VXWIyzrg0hjORxaMYAbH/xyHC/Sy/vvlabpF5n13VuBi
Au/G3grJJRE7jvR0McrEVVG7ZFPXR+In/Bs5EtF2fJ7WUt2dXzNLtjcFgBVt8hAvhFfS
gS2w==
X-Received: by 10.68.197.33 with SMTP id ir1mr19090002pbc.197.1368837050568;
Fri, 17 May 2013 17:30:50 -0700 (PDT)
Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net.
[121.45.44.8]) by mx.google.com with ESMTPSA id
fr1sm13140244pbb.26.2013.05.17.17.30.47 for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Fri, 17 May 2013 17:30:49 -0700 (PDT)
Message-ID: <5196CBB6.90401@HIDDEN>
Date: Sat, 18 May 2013 10:00:46 +0930
From: Michael Zucchi <notzed@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: bug#9088: the jar fragment
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN>
<51945929.3090007@HIDDEN> <5194B075.6060801@HIDDEN>
In-Reply-To: <5194B075.6060801@HIDDEN>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.9 (-)
Hi,
This is my current work on the '.jar' fragment. The rest is just there
to create a working makefile, but the focus of this post is solely on
the 'foo.jar' target fragment.
In-so-far as jar generation goes, this should be 'portable and feature
complete'.
1) Out of source building.
2) In-source tree/generated files
3) 'alternative-root relative' and 'makefile relative' files
4) optional in-source/generated manifest
5) optional main entry point
I have not used (to my knowledge) any gnu-makeisms in the
automake-template-part, and also aimed for portable sh and sed usage.
It should include all the dependencies it needs (at this point).
I presume 'spaces in file names' just isn't supported in general.
(the automake naming conventions and things like the 'build' dir are not
yet done, but are trivial to alter, I need to review all of your
provided information some more first).
It turned out that merging resources/sources wasn't a good idea: it
added complexity and lead to poor dependency behaviour (e.g. add a text
file - compile every jar), so I split them out again. And despite
suggesting it, I actually don't see any need for the SOURCES_PREFIX at
this point.
Because of the way the jar command-line works I decided to add direct
support for the manifest and 'main method' (entry point). I think this
works out cleaner/simpler (and is easier to use) than trying to allow
the user to supply a custom jar command line. _JARFLAGS could still be
used for a couple of aesoteric options.
Background/justification:
Generating a simple jar file is like tar:
jar cf foo.jar files ...
Adding a manifest requires strict ordering:
jar cfm foo.jar manifest.txt files ...
jar cmf manifest.txt foo.jar files ...
Same with also adding a main class entry point:
jar cfme foo.jar manifest.txt au.notzed.Main files ...
But this doesn't work:
jar c -f foo.jar -e au.notzed.Main -m manifest.txt files ...
i.e. the last example could be easily parametrised and allow a
'_JARFLAGS' variable to include these things, but as that isn't the way
jar works, it can't.
The shell script isn't very complicated, it's just bulky. I fully
indented it for clarity. The vpath walk is required several times, and
it has to look-up prefixes on every file. I basically followed how the
java.am did it.
The prefix handling stuff is about one of about 10 different solutions I
tried, everything from awk to sed to plain shell, case statements, etc.
None were any much smaller than the others and this one should be one
of the most portable, and unlike some it requires no automake.in setup.
I have another version which doesn't require sed for the prefix
handling, but i'm not sure how portable the substring/length stuff is (I
spent quite a while searching to try and find out, but search engines
aren't very useful for looking this technical stuff up any more).
It just needs the length and sub-string functions: prefix=${n:0:${#r}};
relname=${n:${#r}}
If those are ok to use it might be a bit more efficient/readable, not
needing to run sed.
!Z
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 17 May 2013 03:51:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 16 23:51:24 2013 Received: from localhost ([127.0.0.1]:48163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UdBhR-0001sc-6I for submit <at> debbugs.gnu.org; Thu, 16 May 2013 23:51:24 -0400 Received: from mail-pb0-f43.google.com ([209.85.160.43]:35504) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <notzed@HIDDEN>) id 1UdBhK-0001sJ-I4 for 9088 <at> debbugs.gnu.org; Thu, 16 May 2013 23:51:19 -0400 Received: by mail-pb0-f43.google.com with SMTP id ma3so1226637pbc.16 for <9088 <at> debbugs.gnu.org>; Thu, 16 May 2013 20:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=5epmtmmvoOd4PyboEm/PBRFMKOiPJJmQGDd/uLMwdXQ=; b=0Etzh7IagdZrfcADy3iuWM4VIVNcbYySYBeoo1RrOVL3mYu3P+CqKds8QVuOR9JGXT WmcUZmYpm2+BgBkEdJ2CXYazLGcg3L88E1RLi/FHiKYUpIZFJWA7cwpvH8d92/E7d+/2 qALUU8NT4b0iBHiuR3cwaVYhsuZ1CJ1MTMBObUuQwBwTp2ny4qFUbrDPoLKGraTY6Rc7 YVK83tiLJTB8TOhYraXYcDuF397IR02ZeWM0vhQ6YGPtM3q6Y2x6JMrZygalhkbyIm2h AklFfmN6SZL4j7/8PN9bL51pqyd8hDvu9G25cIceIZUlg85OS4aIE2DQtDgPIS1b16TS y2IA== X-Received: by 10.66.150.168 with SMTP id uj8mr45768820pab.34.1368762654590; Thu, 16 May 2013 20:50:54 -0700 (PDT) Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net. [121.45.44.8]) by mx.google.com with ESMTPSA id rn7sm9387722pbc.12.2013.05.16.20.50.51 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 20:50:53 -0700 (PDT) Message-ID: <5195A919.9080603@HIDDEN> Date: Fri, 17 May 2013 13:20:49 +0930 From: Michael Zucchi <notzed@HIDDEN> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: bug#9088: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> <518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN> <519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN> <51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN> <51945929.3090007@HIDDEN> <5194B075.6060801@HIDDEN> In-Reply-To: <5194B075.6060801@HIDDEN> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 9088 Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org, Automake List <automake@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) On 16/05/13 19:39, Stefano Lattarini wrote: > On 05/16/2013 05:57 AM, Michael Zucchi wrote: >> On 15/05/13 22:39, Stefano Lattarini wrote: >>> On 05/15/2013 01:52 PM, Michael Zucchi wrote: >>>> On 14/05/13 03:47, Stefano Lattarini wrote: >>>> >> Well if that's a requirement, then it just has to be added right? It's >> not impossible, it's only software ... >> > I failed to parse this. Can you rephrase? It means the problem is an economic one, not a technical one. It's a mostly facetious saying coined by a fellow work-mate which basically means 'we can do whatever you want (but it will cost you)'. Or broken down logically, the technical problem: a) We are solving a problem. b) We are using a general purpose computer to solve it. c) Any problem can be solved by a general purpose computer. d) Therefore, we can solve any problem. (where of course, problem is a computer related problem, which this clearly is) Here the cost is time that could be spent elsewhere, and maybe some lost/grey hairs. >>> Doing too much pre-processing in automake.in (that is, at Automake time) >>> would prevent us from being able to grasp GNU make specific stuff. So >>> let's try to keep such pre-processing at a minimum. >> >> I'm only talking about iterating a list of strings and printing them in >> various ways, i'm pretty sure it does that kind of thing already. >> > Yes, but the price is reduce flexibility at Automake time. Which might > be irrelevant or very important, depending on the expected usage patterns > of a feature. I'm lost here. You seem to be talking about something I haven't even written yet. > OK, then we need integration with javado and juinit. But first let's > try to get the jar stuff right (that seems already non-trivial). Only in-so-much as it isn't identical to a libtool library. And even then libtool gets a leg-up by putting all the messy stuff into another tool. A 'javatool' would likewise make most of the makefile trivial. I'm not proposing such a tool, useful as it might be. >> Not sure why you bothered pointing out the gnu make stuff every time >> when i stated that was a shortcoming for inclusion in automake. >> > Because it is not obvious to me how this usages will be later converted > to be portable. Ahh, I figured you'd be a portable makefile guru working on something like automake and could help work it out. I think with 'b.2' I can do away with the trickier stuff. In 20 odd years i've only ever used gnu make because it can be built anywhere by design. Well apart from maybe some sunos but I think gcc/make were the first tools we installed there anyway. And one windows 7 sdk makefile, but that doesn't even pretend to be a real make. >> My initial version listed every file, and used the gnu-make specific >> extensions in order to make it not "totally suck". But then I ran into >> problems with how to handle resources and rather than work on solving >> those in a way which could fit into an automake.am fragment, I thought >> i'd try the approach I had desired from the start. >> > Given my ignorance of Java, I'm fully ready to change my mind on > this; but then I need examples that are much more clear, complete, > self-explanatory and *working*. I think you should start perusing > the java tests in the 't/' subdirectory of the Automake source tree, > and start writing similar tests that show how you envision your > feature to work in different scenarios. At this stage, using GNU > make specific constructs is OK; I promise I won't bother you about > them anymore. Well the makefile works as much as it was designed to. I don't really understand how the unit tests work. It's a bit frustrating trying to make you enough of a java build expert in a handful of emails when i'm not one myself. Perhaps it's just a lot simpler than you expect - it has far fewer complexities than cross-platform c libraries. >> This particular target was all very simple until i added the LIBADD >> dependencies which meant i could no longer just use $^ as i had. >> >> I couldn't think of a way of having $^ just list .java files whilst >> still depending on the LIBADD stuff for running the compiler but if that >> was possible the problem would vanish. >> > Consider that $^ is not portable to all non-GNU makes, IIRC (but I'm not > 100% sure of this, I'll have to double check), so that we'd likely still > need to rewrite such idioms when we make the transition from your > prototype from the final implementation. Not a big deal right now, but > something worth keeping in mind. Really? Bummer. How does one get the list of requirements then, or is make pretty much hard-coded for C with a single source file using $<? Is $? portable? This is what java.am uses. Not that it's any use here. Obviously it can just use the variables instead, but it then needs to handle srcdir manually. >> Actually the end result I need explicitly for jar is this: >> >> -C $(srcdir)/src a/a.txt \ >> -C $(srcdir)/src b/b.txt \ >> -C $(srcdir)/res c/c.txt >> > But how can the code know, in general, to only strip the first component > of the resources file? That is, why: > > -C res c/c.txt > > and not > > -C src/c c.txt > > ? > > And it gets worse; if you have a resource in a/b/c/d/foo.txt, which one > of these possibilities should be used: > > -C . a/b/c/foo.txt > -C a b/c/foo.txt > -C a/b c/foo.txt > -C a/b/c foo.txt > > ? Oh he finally gets it!!! Yes, this is the problem that needs solving. Which is why EXTRA_DIST's mechanism isn't any use, etc, and so on. I'm sorry i took so long to enunciate it but i thought 'relative root' was fairly obvious. Have you never used zip or tar? Your name suggests there may simply be a language barrier here. >> b.2) >> foo_bar_RESOURCESDIRS = src res >> > (or foo_bar_RESOURCE_PREFIXES even) > >> foo_bar_RESOURCES = src/a/a.txt src/b/b.txt root/c/c.txt >> >> (use regex/sed to strip either root: it can be safely assumed they are >> independent trees so this should be easy) >> > This sounds the best approach so far. I'd love to see a preliminary > implementation of that ;-) Ok. This the one that seems the most simple to implement too. When I have something I will return. > I fear HACKING is quite incomplete in this regard; the best reference > for what can and can't be done portably with POSIX tools in the > Autconf manual, section 11 "Portable Shell Programming": Ok thanks. >> Even if >> every file was listed by hand these capabilities are still going to be >> required. >> >> I notice that automake tends to just use `` instead: >> > What do you intend with `` exactly? Are you referring to command > substitutions? If yes, how are they related to command line limits > issues. What i was talking about was putting the command line arguments in a file, vs putting the command line arguments in a variable. automake tends to use variables. e.g. as a file (a toy example, i know it's wrong) some.jar: $(SRCS) rm -f srcs for n in $(SRCS) ; do \ echo $n | sed 's|^|$(srcdir)|' >> srcs ; \ done javac @srcs rm -f srcs (the "@srcs" reads the arguments from the file) vs (more or less how java.am does it) some.jar: $(SRCS) list1='$(SRCS); list2="" ; for n in $$list1 ; do \ entry=`echo $n | sed 's|^|$(srcdir)|'` ; \ list2="$$list2 $$n" ; \ done ; \ javac $$list2 And as to how they're related to command line limits? `everything inside is a command line is it not`? Every rule action is a command line? > >> aren't command line >> limits a portability issue anymore, or is it just not likely a problem >> with c source? >> > Mostly, it's *extremely* difficult to exceed command line length limits > with a list of sources, unless you are going to build a program or > library (or Jar file, in our case) that has thousands of sources ... Ok i'll just ignore it at this point. Z
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 16 May 2013 10:10:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 16 06:10:23 2013
Received: from localhost ([127.0.0.1]:47051 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Ucv8e-0004GV-Tf
for submit <at> debbugs.gnu.org; Thu, 16 May 2013 06:10:23 -0400
Received: from mail-bk0-f50.google.com ([209.85.214.50]:49330)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1Ucv8a-0004GC-40
for 9088 <at> debbugs.gnu.org; Thu, 16 May 2013 06:10:19 -0400
Received: by mail-bk0-f50.google.com with SMTP id ik5so1552208bkc.9
for <9088 <at> debbugs.gnu.org>; Thu, 16 May 2013 03:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=ODYfWIilLgcVh/Z7KuZgK9ZreVo3xFrj9O6wzxOV2P8=;
b=DI8+HM8OjB2lCl4cWkuCaGInu1gR7VpSaV2mOHV+cgqpbf2H12+SZluVRwEuylJ4Qy
mqiOUDQIc3oYXpfLasadavQrk6yzUG8xbC7a5ZBOJsY05ZSbhhColdjBl2ki1W7PWj5i
lZwJa0sKofJytfA59fXYukwa1XKECC2k7YBzJf875UjMJ5UlDk+bqhELGqu8BbmAsUYv
KikDFJDPBrSHrubkmu+6w6mUZ4YQU4wDBUHXU2LJYWi3PD/3kCftXK10MkaG1ilB0ZEE
2uUSeREuBK3K7w2mPqLQT4fIH3pazUQOtRhJip0eK9GvUUjVWlT09zVQ4XrELR9zhv4i
zpdQ==
X-Received: by 10.204.65.69 with SMTP id h5mr12520566bki.59.1368699000626;
Thu, 16 May 2013 03:10:00 -0700 (PDT)
Received: from [192.168.178.20]
(host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93])
by mx.google.com with ESMTPSA id cl14sm1787929bkb.6.2013.05.16.03.09.58
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 16 May 2013 03:09:59 -0700 (PDT)
Message-ID: <5194B075.6060801@HIDDEN>
Date: Thu, 16 May 2013 12:09:57 +0200
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Michael Zucchi <notzed@HIDDEN>
Subject: Re: bug#9088: Java, JARS primary?
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN>
<51945929.3090007@HIDDEN>
In-Reply-To: <51945929.3090007@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
On 05/16/2013 05:57 AM, Michael Zucchi wrote:
> On 15/05/13 22:39, Stefano Lattarini wrote:
>> On 05/15/2013 01:52 PM, Michael Zucchi wrote:
>>> On 14/05/13 03:47, Stefano Lattarini wrote:
>>>
>>>> Instead, let's start implementing something *correct*, in line with
>>>> the Java philosophy, and with a clean API. We'll think about enhancing
>>>> it when (and if!) the need arise.
>
> And then most of the objections are from trying the java way. Oh well.
>
>>> Seems the way to go.
>>>
>>> On that, here are a few more thoughts on java's specific way of doing
>>> things ...
>>>
>>> files vs dirs
>>> --------------
>>>
>>> java projects/build systems tend to have a fairly basic mechanism to
>>> define the source tree(s) which would be nice to emulate, but may not
>>> fit well with the portability requirements of automake.
>>>
>>> They simply define the root directory and let the build system do the rest.
>>>
>>> Not necessary but would be nice. Or put another way it would basically
>>> suck if it required every source file to be listed explicitly and auto*
>>> having to be re-run every time one is added.
>>>
>> But then, how could make handle the case of generated java files? I.e.,
>> if half of your files are generated by (say) an awk+sed incantation,
>> make has to know it must build them before trying to call the java compiler.
>> But see below.
>
> Well if that's a requirement, then it just has to be added right? It's
> not impossible, it's only software ...
>
I failed to parse this. Can you rephrase?
> Either explicitly listed separately or handled automatically, it's quite
> easy to tell a file from a directory.
>
Ah, OK, so you mean something like the following:
jar_JARS = foo.jar
# All .java files in directory 'foo' ...
foo_jar_SOURCES = foo/
# ... plus this one that is not expected to be present at automake
# time, but will be generated by make.
foo_jar_SOURCES += foo/generated.java
>>> In a GNU makefile I can
>>> just use $(shell find) (or other fancier stuff), but for automake?
>>>
>> The solution is simpler than it seems at first sight: we should just
>
> Actually it isn't quite that simple. I did consider this. More below
> about resources.
>
>> For an example of how this approach could work, take a look at the
>> EXTRA_DIST support (and to the test 't/extra-dist-wildcards-gnu.sh').
>
> Although ... one can specify directories to EXTRA_DIST (even if not
> recommended).
>
> EXTA_DIST is defined relative to the makefile it is in,
>
Correct.
> but that isn't good enough. It works fine for a root makefile since well,
> it's generating the source tree and that is by definition relative to the
> root makefile.
>
I'm lost again. EXTRA_DIST is routinely used in subdir Makefiles ...
> For jars it needs to be relative to a another location
> which is relative to the makefile.
>
Failed to parse, sorry (and my utter ignorance about the Java world
is not helping me out here).
> The bit about nobase in the manual has an impractical solution of
> listing every directory separately.
>
But 'nobase_' is only needed for files that are going to be installed.
In our case, no .java, .class or resource file is going to be installed;
they are going to be used to create the .jar files, and *that* is going
to be installed.
> Somehow the makefile needs this information, either by listing it or by
> it's location, it cannot determine it automatically. More detail and an
> example well below.
>
>>> makefile location
>>> -----------------
>>>
>>> C projects often have a make file per directory, java has the build
>>> script at the top-level at least, outside of the source trees.
>>>
>>> This is desirable.
>>>
>> In some ways, this is desirable also for C projects actually; see the
>> article "Recursive Make Considered Harmful" from Peter Miller:
>>
>> <http://miller.emu.id.au/pmiller/books/rmch/>
>
> Yeah well that's just an opinion. I don't like it myself because it
> makes emacs a total pain to use and I personally consider that pretty
> important.
>
>>> For the resource files the Makefile needs to resolve the resource root,
>>> and strip it out of the names used for the dependencies. So either it
>>> needs a (set of) explicit resource_root, resource_root_files variables,
>>> or it just needs to be defined as the root dir and handled either in the
>>> makefile fragment or in automake.in.
>>>
>> Doing too much pre-processing in automake.in (that is, at Automake time)
>> would prevent us from being able to grasp GNU make specific stuff. So
>> let's try to keep such pre-processing at a minimum.
>
> I'm only talking about iterating a list of strings and printing them in
> various ways, i'm pretty sure it does that kind of thing already.
>
Yes, but the price is reduce flexibility at Automake time. Which might
be irrelevant or very important, depending on the expected usage patterns
of a feature.
> It wont be running find or walking directory trees since that doesn't
> provide anything useful at 'make' time.
>
>>> javadoc, jni, check/test, etc
>>> ------------------------
>>>
>>> Some built-in support would be good. javadoc is easy, check/test should
>>> run junit tests I guess although i'm not too familiar with junit,
>>>
>> Or we might leave that to the use from now (they can use the 'check-local'
>> target), and maybe implement it in a later Automake version, once an usage
>> pattern has emerged (and most importantly, *if* there actually is any
>> request in that direction).
>
> javadoc+test are pretty important in the java world, and of course
> documentation is a critical component for any free software. jni is
> just a personal need and I am familiar with how it works. I also bring
> up jni because this is one area where java build tools really don't
> stack up at all and automake some non-zero chance of becoming a primary
> contender.
>
OK, then we need integration with javado and juinit. But first let's
try to get the jar stuff right (that seems already non-trivial).
> I'm afraid based on the state of things that 'waiting for a request'
> will be a rather long wait ... the horse has quite bolted on the 'build
> tool' front in the last few years for all languages, and one can only
> surmise it was due to the complexity/inadequacy of the ones we already
> had. It's hard to argue that auto* wasn't part of the reason many of
> these tools exist in the first place (i doubt anyone remember imake).
> Pity all the new ones tend to suck in their own ways not least of which
> being they all still suffer from the learning curve issue.
>
>>> first cut
>>> ---------
>>>
>>> I've attached a pretty nasty bit of unportable makefile which attempts
>>> some of the above to see how it might be done.
>>>
>> Comments for that are below. I understand this is just a preliminary and
>> rough implementation, so please don't allow my doubts and criticism blow
>> your morale.
>
> Not sure why you bothered pointing out the gnu make stuff every time
> when i stated that was a shortcoming for inclusion in automake.
>
Because it is not obvious to me how this usages will be later converted
to be portable.
OTOH, we might decide to simplify our lives and just require GNU make to
be used to run Makefiles implementing Java support (we already do so for
Vala support). What is the percentage of machines out there that have
'javac' installed and but lack GNU make?
>> BTW, while writing this first draft, have taken into consideration all
>> the comments in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088>,
>> as well as the extensive and (AFAICS) *working* code at
>> <https://github.com/stumbleupon/opentsdb/blob/6059488/Makefile#L207>?
>> We cannot allow all those earlier thoughts and efforts go wasted ...
>
> Yeah I looked at both of those, and the java.am stuff.
>
>>> The build steps from this are simple:
>>>
>>> $ rm foo_jar.stamp ; make -f Auto.mak
>>> javac -cp lib/jjmpeg.jar:lib/test.jar -sourcepath src -d
>>> build/classes/foo_jar src/z/util/d.java src/z/util/c.java src/z/a.java
>>> src/z/b.java
>>> touch foo_jar.stamp
>>> jar cf foo.jar -C build/classes/foo_jar . \
>>> -C ./src ./z/util/util-names.txt \
>>> -C ./res ./foo.txt
>>> $
>>>
>>> Regards,
>>> Michael
>>
>>> ===== Auto.mak =====
>>>
>>> # default is /usr/share/java/package ?
>>> jardir = $(datadir)/java/@PACKAGE@
>>>
>> Or simply '$(datadir)/java'; then we can pre-define pkgjardir
>> to be '$(datadir)/java/$(PACKAGE)'. Something similar is
>> already done for datadir, includedir, libdir, and libexecdir:
>> <http://www.gnu.org/software/automake/manual/automake.html#index-pkglibdir-131>
>
> I don't really know on this one. I'm just looking at where java stuff
> is installed on my fedora system - although i never use any of that
> because it's easier/safer (configuration wise) to just include all the
> jars in my own packages particularly when supporting cross-platform
> applications.
>
> I guess any jar installed into /usr/share/java would want a version in
> it's name.
>
>>> srcdir=.
>>>
>> Just a reminder: we must also be prepared to handle VPATH builds, that
>> is, '$(srcdir)' != '.'; no need to think about this right away, but it
>> should be made to work before the feature is integrated in Automake (so
>> we want a design that will allow it to work!)
>
> srcdir is just set so that i have a working standalone makefile but can
> still follow some automake conventions inside of it to demonstrate the
> principle. I was going to add a comment to that effect but thought it
> might've been a little ... obvious.
>
> I thought i stated that I think it should support a vpath build, but I
> haven't yet tested that. So yes, I have already thought about it and
> it's something i'm quite well aware of.
>
OK.
>>> all: foo.jar
>>>
>>> jar_JARS=foo.jar
>>>
>>> foo_jar_SOURCES = src
>>>
>> NAK. We should make the use list all the Java files, while (as said
>> before) being able to support GNU make extensions in the definition
>> of this variable. Unless you have strong objections to this idea;
>> objections which I'd like to hear ASAP.
>
> Well it was just an alternative. This is the alternative I would like,
> and I'm pretty sure every normal java developer would expect. If they
> have to manually list every source file every time a new one is added
> and then re-run autostuff, they wouldn't bother ever considering
> automake as it would just totally suck.
>
> So, totally sucking is my only real objection.
>
> My initial version listed every file, and used the gnu-make specific
> extensions in order to make it not "totally suck". But then I ran into
> problems with how to handle resources and rather than work on solving
> those in a way which could fit into an automake.am fragment, I thought
> i'd try the approach I had desired from the start.
>
Given my ignorance of Java, I'm fully ready to change my mind on
this; but then I need examples that are much more clear, complete,
self-explanatory and *working*. I think you should start perusing
the java tests in the 't/' subdirectory of the Automake source tree,
and start writing similar tests that show how you envision your
feature to work in different scenarios. At this stage, using GNU
make specific constructs is OK; I promise I won't bother you about
them anymore.
> I have some more thoughts lower, and in general they work either way.
>
>>> # same as in the way one would add a in-package libtool lib, but
>>> # this is in the build jar path
>>> foo_jar_LIBADD = lib/jjmpeg.jar lib/test.jar
>>>
>> Sounds good. But maybe s/LIBADD/JARADD/?
>
> Could be anything. I followed the way libtool does it. Previous
> comments in the bug seemed to suggest the desirability of sticking with
> existing names, so it wasn't a totally arbitrary choice.
>
And anyway, not a problem worth worrying about right now. Better to
revisit it later, if needed. Sorry for brining it up right away and
compounding to the confusion.
>> In addition, "mkdir -p" is unfortunately not multithred-safe on all platforms.
>> We have code that should work around the issue; to take advantage of that,
>> just use the $(MKDIR_P) macro instead of "mkdir -p".
>
> ok no worries.
>
>>> javac -cp $(foo_jar_CLASSPATH) -sourcepath src -d build/classes/foo_jar $(filter %.java,$^)
>>>
>> We cannot unilaterally squat on a common file/directry name like "build"
>> here. No need to fix that right now though; we can easily return on the
>> issue later.
>
> This is just what ant uses, and not surprisingly, it could be anything.
> As a developer I would prefer it wasn't hidden but it's kind of here
> nor there. No java tools I know ever hide it, it's a critical path in
> the build process and one can just run code from there, ignoring any jar
> file.
>
No need to hide it; and it's pretty easy to make it configurable, as
with:
AM_JAVA_OUTDIR = build # What ant does.
# ... later in the rules:
javac -cp $(foo_jar_CLASSPATH) -sourcepath src -d $(AM_JAVA_OUTDIR)/classes/foo_jar ...
> I think a documented/makefile usable location will be needed for tools
> that work on the class files, but I don't have familarity with those.
>
>> Also, the '$(filter %.java,$^)' is GNU make specific; it should be juse
>> substituted by $(foo_jar_SOURCES), no?
>
> Yes I know I was using gnu make extensions.
>
> Well, no, $(foo_jar_SOURCES) can't be used, at least not directly.
> It doesn't expand VPATH as the dependencies do but it could (obviously!)
> just use a similar approach as in the current java.am file. Although
> that also uses the expanded dependencies so it would still need to
> filter out .java files.
>
> This particular target was all very simple until i added the LIBADD
> dependencies which meant i could no longer just use $^ as i had.
>
> I couldn't think of a way of having $^ just list .java files whilst
> still depending on the LIBADD stuff for running the compiler but if that
> was possible the problem would vanish.
>
Consider that $^ is not portable to all non-GNU makes, IIRC (but I'm not
100% sure of this, I'll have to double check), so that we'd likely still
need to rewrite such idioms when we make the transition from your
prototype from the final implementation. Not a big deal right now, but
something worth keeping in mind.
>>> touch $@
>>>
>>
>>> foo.jar: foo_jar.stamp $(patsubst %,src/%,$(foo_jar_RESOURCES_list0)) $(patsubst %,res/%,$(foo_jar_RESOURCES_list1))
>>> jar cf $@ -C build/classes/foo_jar . \
>>> $(patsubst %,-C $(srcdir)/src %,$(foo_jar_RESOURCES_list0)) \
>>> $(patsubst %,-C $(srcdir)/res %,$(foo_jar_RESOURCES_list1))
>>>
>> This is too much GNU make specific. Moreover, I have zero knowledge about
>> how the "Java resources" are expected to work, so I don't know how to
>> suggest fixes or improvements. Do you have links to noob-understendable
>> documentation that explains in enough detail what Java resources are and
>> how they are suppose to work?
>
> Yes I know I was using gnu make extensions.
>
> As previously explained they're typically just every file in the source
> tree which doesn't end in '.java' but they could be from (multiple) other
> trees. I never read any documentation about this I just picked it up
> osmoticly[sic] from using netbeans. Unlike other languages, java files
> really must end in '.java', so the distinction is easy.
>
> They can be anything that is app-specific but there are also others
> which are to support java meta-data such as service plugin hooks. But
> at the end of the day they're just files in a directory tree. Obviously
> this means that a jar may also be purely data with no code whatsoever.
>
> Newbie: It's a zip file of a directory tree of files. It can contain
> anything a zip can.
>
> It is definitely a hard requirement that they be able to be placed into
> the source tree in addition to other locations. And this is why ...
>
> e.g. a source tree:
>
> a/a.java
> a/a.txt
>
> jar:
>
> a/a.class
> a/a.txt
>
> a.java fragment:
>
> InputStream a.class.getResourceAsStream("a.txt");
>
> i.e. a class has direct access to these resources relative to it's own
> class. They are just loaded from the zip at runtime.
>
OK, got it. Thanks for the dumbed-down explanation.
> The problem is this:
>
> a) the jar needs to depend on the resources, they need to be defined
> relative to the makefile
>
> b) to include the files in the jar command, they need to be specified as
> they appear in the jar file, i.e. relative to the jar root.
>
> c) with no a-priori knowledge of the root directory in which the
> resources reside, how can these two independent file lists be created?
> And support multiple directory trees?
>
> This problem does not arise as such with the building of the java source
> because the compiler is already doing the translation for you, and the
> individual .class files are not tracked by make. However, the problem
> does arise with extra class files which might be included/created
> somewhere else.
>
> c is not an issue with EXTRA_DIST because the root directory is known
> a-priori due to it being where the Makefile is.
>
> Basically say I have this:
>
> foo_jar_RESOURCES=src/a/a.txt src/b/b.txt res/c/c.txt
>
> I need two results from this input (taking into account out of source
> builds with the abstract use of $(srcdir) here, regardless of whether
> this is the correct automake foo or not):
>
> 1) dependencies: $(srcdir)/src/a/a.txt $(srcdir)/src/a/a.txt
> $(srcdir)/res/c/c.txt
> - this is just handled by VPATH already and so happens automagically
> 'for free'.
>
> 2) relative paths (and their corresponding root):
>
> root $(srcdir)/src files a/a.txt b/b.txt
> root $(srcdir)/res files c/c.txt
>
> Actually the end result I need explicitly for jar is this:
>
> -C $(srcdir)/src a/a.txt \
> -C $(srcdir)/src b/b.txt \
> -C $(srcdir)/res c/c.txt
>
But how can the code know, in general, to only strip the first component
of the resources file? That is, why:
-C res c/c.txt
and not
-C src/c c.txt
?
And it gets worse; if you have a resource in a/b/c/d/foo.txt, which one
of these possibilities should be used:
-C . a/b/c/foo.txt
-C a b/c/foo.txt
-C a/b c/foo.txt
-C a/b/c foo.txt
?
> However this can be in a file rather than a command argument (and
> doesn't need the newline escapes then).
>
> Ideally jar could be used directly for this, alternatively a staging
> area could be used but this would slow the build down/waste disk space.
>
> Possible solutions (not exhaustive, not suggestions):
>
> a) As included in the makefile so far. Supply the roots and let the
> script handle everything. It has enough information to do everything
> required. This is how every java coder on the planet will want and
> expect it to work.
>
> b) specify each resource root using multiple variables.
>
> Possible non-suggestions:
>
> b.0)
> foo_bar_RESOURCES = src res ../android/res
> foo_bar_src_RESOURCES = a/a.txt b/b.txt
> foo_bar_res_RESOURCES = c/c.txt
> foo_bar____android_res_RESOURCES = pics/bob.jpg
>
> (obvious problems with relative paths with this idea)
>
And doesn't integrate well with the typical Automake naming scheme.
That is, 'foo_bar_src_RESOURCES' would suggest you have a
'foo/bar/src.jar' Jar file to build ...
> b.1)
> foo_bar_RESOURCES_anything = src
> foo_bar_RESOURCES_anything_FILES = a/a.txt b/b.txt
> foo_bar_RESOURCES_blah = res
> foo_bar_RESOURCES_blah_FILES = c/c.txt
> etc.
>
> b.2)
> foo_bar_RESOURCESDIRS = src res
>
(or foo_bar_RESOURCE_PREFIXES even)
> foo_bar_RESOURCES = src/a/a.txt src/b/b.txt root/c/c.txt
>
> (use regex/sed to strip either root: it can be safely assumed they are
> independent trees so this should be easy)
>
This sounds the best approach so far. I'd love to see a preliminary
implementation of that ;-)
> b.3) Something more implicit like the way nobase_ works, but i don't
> know how you'd define the root in that case.
>
> There may be automake.in conventions which make these or other
> arrangements more desirable. But whatever it is this basic information
> is required in the end: a root and a list relative to that root.
>
> c) Define everything twice. The 'jar' name (plus root, somehow), and
> the 'dependency name'.
>
> d) force individual makefiles into the 'src' or 'res' roots. Then
> require everything to be copied into a staging area. Then use another
> makefile to create the actual jar.
>
> e) List every source dir and target dir by hand (example given in the
> nobase_ part of the manual S7.3 - node 'Alternative').
>
> Judgments:
>
> a) nicest to user.
>
But might be problematic to implement, and goes against Automake's
"Uniform Naming Scheme".
> b) bearable.
>
And logical, easy to grasp, and simple for the user to control.
> c) sucks, messy
> d) slow, messy, painful to use.
> e) ugh.
>
> Whatever it is the same mechanism should probably be used for multiple
> source trees and pre-existing/make-generated class trees.
>
> Actually just using SOURCES alone would work for everything (i.e. no
> _RESOURCES stuff, but it still needs to know the relative root), and
> just filter out '.java' for the resources/extra classes.
>
I'm OK with this unified approach, as long as it doesn't complicate the
implementation.
> This is
> assuming one never wanted a .java source file in such a generated jar,
> which I think is a fairly reasonable assumption as these are about code
> not source.
>
Agreed.
>>
>>> .PHONY javadoc: javadoc-foo_jar
>>> javadoc-foo_jar:
>>> exit 1
>>> build javadoc stuff, not done yet
>>>
>>
>> Is see that we still lack clean and installation rules. They are quite
>> important, and should be introduced ASAP.
>
> These are just trivialities. I thought i'd get the hard problems out of
> the way before giving you a final solution you wouldn't accept anyway -
> i know how this works. I was worried the fragment presented wasn't
> complete enough but now i'm glad I didn't spend more time on it before
> feedback.
>
> You seem to have got quite hung up on the gnu make stuff even though i
> stated that wasn't a consideration at this point.
>
Not a show stopper, but we have to avoid painting ourselves in a corner
by using GNU make features that we then are not able to "port" to non-GNU
makes (unlikely, but possible). Or we can decide up-front to require
GNU make unconditionally for the Java support, and forger about the
portability issues.
> Obviously anything it
> does can be implemented using sed or grep, and java tools allow
> arguments to be placed into files for better scalability.
>
> Questions then arise: what of such basic tools can be used,
>
Basically, the POSIX tools (sed, grep, awk, etc), avoiding all GNU
extensions. But don't overly worry about that, its easy for us to
spot and fix possible unportable uses. Just don't get upset by the
associated nitpicking ;-)
> and what
> limitations on filenames must be adhered to should they be used for
> argument lists (if this is in hacking just leave it at that).
>
I fear HACKING is quite incomplete in this regard; the best reference
for what can and can't be done portably with POSIX tools in the
Autconf manual, section 11 "Portable Shell Programming":
<http://www.gnu.org/software/autoconf/manual/autoconf.html#Portable-Shell>
(no, you are not supposed to read all of that, don't worry :-)
> Even if
> every file was listed by hand these capabilities are still going to be
> required.
>
> I notice that automake tends to just use `` instead:
>
What do you intend with `` exactly? Are you referring to command
substitutions? If yes, how are they related to command line limits
issues.
> aren't command line
> limits a portability issue anymore, or is it just not likely a problem
> with c source?
>
Mostly, it's *extremely* difficult to exceed command line length limits
with a list of sources, unless you are going to build a program or
library (or Jar file, in our case) that has thousands of sources ...
> !Z
Regards,
Stefano
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 16 May 2013 03:57:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 15 23:57:53 2013
Received: from localhost ([127.0.0.1]:46795 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UcpKB-0006ZW-KP
for submit <at> debbugs.gnu.org; Wed, 15 May 2013 23:57:53 -0400
Received: from mail-pa0-f41.google.com ([209.85.220.41]:46901)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <notzed@HIDDEN>) id 1UcpK7-0006ZD-ON
for 9088 <at> debbugs.gnu.org; Wed, 15 May 2013 23:57:50 -0400
Received: by mail-pa0-f41.google.com with SMTP id rl6so2114096pac.0
for <9088 <at> debbugs.gnu.org>; Wed, 15 May 2013 20:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:cc
:subject:references:in-reply-to:x-enigmail-version:content-type
:content-transfer-encoding;
bh=zrosaH+isuy6Be9vWcTUOKByUEfn44saw4z3PM6MKwQ=;
b=uAOwMdnnzI0d9luu+gJrQHd/7WqD2ipPVAa6JMIUIZFiwnlb3Gf22efjfrsrl9WA3L
A2rjP+Xc592aMsQ10v7A7pW9qmlCfeHbcstCRZx0OQfyeMED+KW12+J2U1Q856jhJyl/
mbJyTdkaRo3EbsGABMzHP58mQzJZhctU/1GSM3foTnEbVxjP399alcvlwl9AcnMfz5cI
o42zQ5Gcq1rQk7p7812+GdHVqp8t15UIBbyq/qiJLUzryWO07jT+XEbj8Nbd3zcYwiZX
DiHsHJZie5F0oupIzjEHT/RswCedkHTJ1UBVglJpHqKYgd/lYfGpV+KW4nfL3zwp4juU
NNiw==
X-Received: by 10.66.245.110 with SMTP id xn14mr41824014pac.130.1368676653718;
Wed, 15 May 2013 20:57:33 -0700 (PDT)
Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net.
[121.45.44.8])
by mx.google.com with ESMTPSA id az5sm5080500pbc.18.2013.05.15.20.57.30
for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 15 May 2013 20:57:33 -0700 (PDT)
Message-ID: <51945929.3090007@HIDDEN>
Date: Thu, 16 May 2013 13:27:29 +0930
From: Michael Zucchi <notzed@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: bug#9088: Java, JARS primary?
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN> <51938906.2000903@HIDDEN>
In-Reply-To: <51938906.2000903@HIDDEN>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
On 15/05/13 22:39, Stefano Lattarini wrote:
> On 05/15/2013 01:52 PM, Michael Zucchi wrote:
>> On 14/05/13 03:47, Stefano Lattarini wrote:
>>
>>> Instead, let's start implementing something *correct*, in line with
>>> the Java philosophy, and with a clean API. We'll think about enhancing
>>> it when (and if!) the need arise.
And then most of the objections are from trying the java way. Oh well.
>> Seems the way to go.
>>
>> On that, here are a few more thoughts on java's specific way of doing
>> things ...
>>
>> files vs dirs
>> --------------
>>
>> java projects/build systems tend to have a fairly basic mechanism to
>> define the source tree(s) which would be nice to emulate, but may not
>> fit well with the portability requirements of automake.
>>
>> They simply define the root directory and let the build system do the rest.
>>
>> Not necessary but would be nice. Or put another way it would basically
>> suck if it required every source file to be listed explicitly and auto*
>> having to be re-run every time one is added.
>>
> But then, how could make handle the case of generated java files? I.e.,
> if half of your files are generated by (say) an awk+sed incantation,
> make has to know it must build them before trying to call the java compiler.
> But see below.
Well if that's a requirement, then it just has to be added right? It's
not impossible, it's only software ...
Either explicitly listed separately or handled automatically, it's quite
easy to tell a file from a directory.
>> In a GNU makefile I can
>> just use $(shell find) (or other fancier stuff), but for automake?
>>
> The solution is simpler than it seems at first sight: we should just
Actually it isn't quite that simple. I did consider this. More below
about resources.
> For an example of how this approach could work, take a look at the
> EXTRA_DIST support (and to the test 't/extra-dist-wildcards-gnu.sh').
Although ... one can specify directories to EXTRA_DIST (even if not
recommended).
EXTA_DIST is defined relative to the makefile it is in, but that isn't
good enough. It works fine for a root makefile since well, its'
generating the source tree and that is by definition relative to the
root makefile. For jars it needs to be relative to a another location
which is relative to the makefile.
The bit about nobase in the manual has an impractical solution of
listing every directory separately.
Somehow the makefile needs this information, either by listing it or by
it's location, it cannot determine it automatically. More detail and an
example well below.
>> makefile location
>> -----------------
>>
>> C projects often have a make file per directory, java has the build
>> script at the top-level at least, outside of the source trees.
>>
>> This is desirable.
>>
> In some ways, this is desirable also for C projects actually; see the
> article "Recursive Make Considered Harmful" from Peter Miller:
>
> <http://miller.emu.id.au/pmiller/books/rmch/>
Yeah well that's just an opinion. I don't like it myself because it
makes emacs a total pain to use and I personally consider that pretty
important.
>> For the resource files the Makefile needs to resolve the resource root,
>> and strip it out of the names used for the dependencies. So either it
>> needs a (set of) explicit resource_root, resource_root_files variables,
>> or it just needs to be defined as the root dir and handled either in the
>> makefile fragment or in automake.in.
>>
> Doing too much pre-processing in automake.in (that is, at Automake time)
> would prevent us from being able to grasp GNU make specific stuff. So
> let's try to keep such pre-processing at a minimum.
I'm only talking about iterating a list of strings and printing them in
various ways, i'm pretty sure it does that kind of thing already. It
wont be running find or walking directory trees since that doesn't
provide anything useful at 'make' time.
>> javadoc, jni, check/test, etc
>> ------------------------
>>
>> Some built-in support would be good. javadoc is easy, check/test should
>> run junit tests I guess although i'm not too familiar with junit,
>>
> Or we might leave that to the use from now (they can use the 'check-local'
> target), and maybe implement it in a later Automake version, once an usage
> pattern has emerged (and most importantly, *if* there actually is any
> request in that direction).
javadoc+test are pretty important in the java world, and of course
documentation is a critical component for any free software. jni is
just a personal need and I am familiar with how it works. I also bring
up jni because this is one area where java build tools really don't
stack up at all and automake some non-zero chance of becoming a primary
contender.
I'm afraid based on the state of things that 'waiting for a request'
will be a rather long wait ... the horse has quite bolted on the 'build
tool' front in the last few years for all languages, and one can only
surmise it was due to the complexity/inadequacy of the ones we already
had. It's hard to argue that auto* wasn't part of the reason many of
these tools exist in the first place (i doubt anyone remember imake).
Pity all the new ones tend to suck in their own ways not least of which
being they all still suffer from the learning curve issue.
>> first cut
>> ---------
>>
>> I've attached a pretty nasty bit of unportable makefile which attempts
>> some of the above to see how it might be done.
>>
> Comments for that are below. I understand this is just a preliminary and
> rough implementation, so please don't allow my doubts and criticism blow
> your morale.
Not sure why you bothered pointing out the gnu make stuff every time
when i stated that was a shortcoming for inclusion in automake.
> BTW, while writing this first draft, have taken into consideration all
> the comments in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088>,
> as well as the extensive and (AFAICS) *working* code at
> <https://github.com/stumbleupon/opentsdb/blob/6059488/Makefile#L207>?
> We cannot allow all those earlier thoughts and efforts go wasted ...
Yeah I looked at both of those, and the java.am stuff.
>> The build steps from this are simple:
>>
>> $ rm foo_jar.stamp ; make -f Auto.mak
>> javac -cp lib/jjmpeg.jar:lib/test.jar -sourcepath src -d
>> build/classes/foo_jar src/z/util/d.java src/z/util/c.java src/z/a.java
>> src/z/b.java
>> touch foo_jar.stamp
>> jar cf foo.jar -C build/classes/foo_jar . \
>> -C ./src ./z/util/util-names.txt \
>> -C ./res ./foo.txt
>> $
>>
>> Regards,
>> Michael
>
>> ===== Auto.mak =====
>>
>> # default is /usr/share/java/package ?
>> jardir = $(datadir)/java/@PACKAGE@
>>
> Or simply '$(datadir)/java'; then we can pre-define pkgjardir
> to be '$(datadir)/java/$(PACKAGE)'. Something similar is
> already done for datadir, includedir, libdir, and libexecdir:
> <http://www.gnu.org/software/automake/manual/automake.html#index-pkglibdir-131>
I don't really know on this one. I'm just looking at where java stuff
is installed on my fedora system - although i never use any of that
because it's easier/safer (configuration wise) to just include all the
jars in my own packages particularly when supporting cross-platform
applications.
I guess any jar installed into /usr/share/java would want a version in
it's name.
>> srcdir=.
>>
> Just a reminder: we must also be prepared to handle VPATH builds, that
> is, '$(srcdir)' != '.'; no need to think about this right away, but it
> should be made to work before the feature is integrated in Automake (so
> we want a design that will allow it to work!)
srcdir is just set so that i have a working standalone makefile but can
still follow some automake conventions inside of it to demonstrate the
principle. I was going to add a comment to that effect but thought it
might've been a little ... obvious.
I thought i stated that I think it should support a vpath build, but I
haven't yet tested that. So yes, I have already thought about it and
it's something i'm quite well aware of.
>> all: foo.jar
>>
>> jar_JARS=foo.jar
>>
>> foo_jar_SOURCES = src
>>
> NAK. We should make the use list all the Java files, while (as said
> before) being able to support GNU make extensions in the definition
> of this variable. Unless you have strong objections to this idea;
> objections which I'd like to hear ASAP.
Well it was just an alternative. This is the alternative I would like,
and I'm pretty sure every normal java developer would expect. If they
have to manually list every source file every time a new one is added
and then re-run autostuff, they wouldn't bother ever considering
automake as it would just totally suck.
So, totally sucking is my only real objection.
My initial version listed every file, and used the gnu-make specific
extensions in order to make it not "totally suck". But then I ran into
problems with how to handle resources and rather than work on solving
those in a way which could fit into an automake.am fragment, I thought
i'd try the approach I had desired from the start.
I have some more thoughts lower, and in general they work either way.
>> # same as in the way one would add a in-package libtool lib, but
>> # this is in the build jar path
>> foo_jar_LIBADD = lib/jjmpeg.jar lib/test.jar
>>
> Sounds good. But maybe s/LIBADD/JARADD/?
Could be anything. I followed the way libtool does it. Previous
comments in the bug seemed to suggest the desirability of sticking with
existing names, so it wasn't a totally arbitrary choice.
> In addition, "mkdir -p" is unfortunately not multithred-safe on all platforms.
> We have code that should work around the issue; to take advantage of that,
> just use the $(MKDIR_P) macro instead of "mkdir -p".
ok no worries.
>> javac -cp $(foo_jar_CLASSPATH) -sourcepath src -d build/classes/foo_jar $(filter %.java,$^)
>>
> We cannot unilaterally squat on a common file/directry name like "build"
> here. No need to fix that right now though; we can easily return on the
> issue later.
This is just what ant uses, and not surprisingly, it could be anything.
As a developer I would prefer it wasn't hidden but it's kind of here
nor there. No java tools I know ever hide it, it's a critical path in
the build process and one can just run code from there, ignoring any jar
file.
I think a documented/makefile usable location will be needed for tools
that work on the class files, but I don't have familarity with those.
> Also, the '$(filter %.java,$^)' is GNU make specific; it should be juse
> substituted by $(foo_jar_SOURCES), no?
Yes I know I was using gnu make extensions.
Well, no, $(foo_jar_SOURCES) can't be used, at least not directly.
It doesn't expand VPATH as the dependencies do but it could (obviously!)
just use a similar approach as in the current java.am file. Although
that also uses the expanded dependencies so it would still need to
filter out .java files.
This particular target was all very simple until i added the LIBADD
dependencies which meant i could no longer just use $^ as i had.
I couldn't think of a way of having $^ just list .java files whilst
still depending on the LIBADD stuff for running the compiler but if that
was possible the problem would vanish.
>> touch $@
>>
>
>> foo.jar: foo_jar.stamp $(patsubst %,src/%,$(foo_jar_RESOURCES_list0)) $(patsubst %,res/%,$(foo_jar_RESOURCES_list1))
>> jar cf $@ -C build/classes/foo_jar . \
>> $(patsubst %,-C $(srcdir)/src %,$(foo_jar_RESOURCES_list0)) \
>> $(patsubst %,-C $(srcdir)/res %,$(foo_jar_RESOURCES_list1))
>>
> This is too much GNU make specific. Moreover, I have zero knowledge about
> how the "Java resources" are expected to work, so I don't know how to
> suggest fixes or improvements. Do you have links to noob-understendable
> documentation that explains in enough detail what Java resources are and
> how they are suppose to work?
Yes I know I was using gnu make extensions.
As previously explained they're typically just every file in the source
tree which doesn't end in '.java' but they could be from (mutiple) other
trees. I never read any documentation about this I just picked it up
osmoticly[sic] from using netbeans. Unlike other languages, java files
really must end in '.java', so the distinction is easy.
They can be anything that is app-specific but there are also others
which are to support java meta-data such as service plugin hooks. But
at the end of the day they're just files in a directory tree. Obviously
this means that a jar may also be purely data with no code whatsoever.
Newbie: It's a zip file of a directory tree of files. It can contain
anything a zip can.
It is definitely a hard requirement that they be able to be placed into
the source tree in addition to other locations. And this is why ...
e.g. a source tree:
a/a.java
a/a.txt
jar:
a/a.class
a/a.txt
a.java fragment:
InputStream a.class.getResourceAsStream("a.txt");
i.e. a class has direct access to these resources relative to it's own
class. They are just loaded from the zip at runtime.
The problem is this:
a) the jar needs to depend on the resources, they need to be defined
relative to the makefile
b) to include the files in the jar command, they need to be specified as
they appear in the jar file, i.e. relative to the jar root.
c) with no a-priori knowledge of the root directory in which the
resources reside, how can these two independent file lists be created?
And support multiple directory trees?
This problem does not arise as such with the building of the java source
because the compiler is already doing the translation for you, and the
individual .class files are not tracked by make. However, the problem
does arise with extra class files which might be included/created
somewhere else.
c is not an issue with EXTRA_DIST because the root directory is known
a-priori due to it being where the Makefile is.
Basically say I have this:
foo_jar_RESOURCES=src/a/a.txt src/b/b.txt res/c/c.txt
I need two results from this input (taking into account out of source
builds with the abstract use of $(srcdir) here, regardless of whether
this is the correct automake foo or not):
1) dependencies: $(srcdir)/src/a/a.txt $(srcdir)/src/a/a.txt
$(srcdir)/res/c/c.txt
- this is just handled by VPATH already and so happens automagically
'for free'.
2) relative paths (and their corresponding root):
root $(srcdir)/src files a/a.txt b/b.txt
root $(srcdir)/res files c/c.txt
Actually the end result I need explicitly for jar is this:
-C $(srcdir)/src a/a.txt \
-C $(srcdir)/src b/b.txt \
-C $(srcdir)/res c/c.txt
However this can be in a file rather than a command argument (and
doesn't need the newline escapes then).
Ideally jar could be used directly for this, alternatively a staging
area could be used but this would slow the build down/waste disk space.
Possible solutions (not exhaustive, not suggestions):
a) As included in the makefile so far. Supply the roots and let the
script handle everything. It has enough information to do everything
required. This is how every java coder on the planet will want and
expect it to work.
b) specify each resource root using multiple variables.
Possible non-suggestions:
b.0)
foo_bar_RESOURCES = src res ../android/res
foo_bar_src_RESOURCES = a/a.txt b/b.txt
foo_bar_res_RESOURCES = c/c.txt
foo_bar____android_res_RESOURCES = pics/bob.jpg
(obvious problems with relative paths with this idea)
b.1)
foo_bar_RESOURCES_anything = src
foo_bar_RESOURCES_anything_FILES = a/a.txt b/b.txt
foo_bar_RESOURCES_blah = res
foo_bar_RESOURCES_blah_FILES = c/c.txt
etc.
b.2)
foo_bar_RESOURCESDIRS = src res
foo_bar_RESOURCES = src/a/a.txt src/b/b.txt root/c/c.txt
(use regex/sed to strip either root: it can be safely assumed they are
independent trees so this should be easy)
b.3) Something more implicit like the way nobase_ works, but i don't
know how you'd define the root in that case.
There may be automake.in conventions which make these or other
arrangements more desirable. But whatever it is this basic information
is required in the end: a root and a list relative to that root.
c) Define everything twice. The 'jar' name (plus root, somehow), and
the 'dependency name'.
d) force individual makefiles into the 'src' or 'res' roots. Then
require everything to be copied into a staging area. Then use another
makefile to create the actual jar.
e) List every source dir and target dir by hand (example given in the
nobase_ part of the manual S7.3 - node 'Alternative').
a) nicest to user.
b) bearable.
c) sucks, messy
d) slow, messy, painful to use.
e) ugh.
Whatever it is the same mechanism should probably be used for multiple
source trees and pre-existing/make-generated class trees.
Actually just using SOURCES alone would work for everything (i.e. no
_RESOURCES stuff, but it still needs to know the relative root), and
just filter out '.java' for the resources/extra classes. This is
assuming one never wanted a .java source file in such a generated jar,
which I think is a fairly reasonable assumption as these are about code
not source.
>
>> .PHONY javadoc: javadoc-foo_jar
>> javadoc-foo_jar:
>> exit 1
>> build javadoc stuff, not done yet
>>
>
> Is see that we still lack clean and installation rules. They are quite
> important, and should be introduced ASAP.
These are just trivialities. I thought i'd get the hard problems out of
the way before giving you a final solution you wouldn't accept anyway -
i know how this works. I was worried the fragment presented wasn't
complete enough but now i'm glad I didn't spend more time on it before
feedback.
You seem to have got quite hung up on the gnu make stuff even though i
stated that wasn't a consideration at this point. Obviously anything it
does can be implemented using sed or grep, and java tools allow
arguments to be placed into files for better scalability.
Questions then arise: what of such basic tools can be used, and what
limitations on filenames must be adhered to should they be used for
argument lists (if this is in hacking just leave it at that). Even if
every file was listed by hand these capabilities are still going to be
required.
I notice that automake tends to just use `` instead: aren't command line
limits a portability issue anymore, or is it just not likely a problem
with c source?
!Z
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 15 May 2013 13:09:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 15 09:09:51 2013
Received: from localhost ([127.0.0.1]:45536 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UcbSn-0002GQ-FS
for submit <at> debbugs.gnu.org; Wed, 15 May 2013 09:09:50 -0400
Received: from mail-ee0-f53.google.com ([74.125.83.53]:50790)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1UcbSj-0002Fx-UR
for 9088 <at> debbugs.gnu.org; Wed, 15 May 2013 09:09:48 -0400
Received: by mail-ee0-f53.google.com with SMTP id c1so704647eek.26
for <9088 <at> debbugs.gnu.org>; Wed, 15 May 2013 06:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=yUayrnRHJ2b4HAb3FwllISf8GzeYc4SvaqQ3zjH34J8=;
b=t/bvLZCDYm3NvZCnrXMaznnqJpmoPb96kmUIBQzKCvyCT2GKEGGk8EI+H9dvhAlOdi
lZElSTZPrLDwSxqBrYCU3Y4Nj9kdmi0GJBekX9+edfK0nIvNdIbbDZ191aHsNcpdVmoU
XHzMBhSHkaIkirLxHJMAY/ar1bYwz1RlyC/s3MkSp750XqzWLMPkXqzzkItQm40wOi+r
kYmnRtNXyM6tBVPG0cgUvDoUeMnamiHfK+jDopxki8/WJP84MP38GM6en/+3sLvmVqkN
axxyjbzQ3ZupF4T2KyJjV4tysBWdJ+DrmLZKMTzPe3mUGZCjtm4UbmCwWyZoSTZqXSG1
IDOg==
X-Received: by 10.14.3.4 with SMTP id 4mr44285418eeg.8.1368623375304;
Wed, 15 May 2013 06:09:35 -0700 (PDT)
Received: from [192.168.178.20]
(host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93])
by mx.google.com with ESMTPSA id t9sm3836964eeo.11.2013.05.15.06.09.33
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 15 May 2013 06:09:34 -0700 (PDT)
Message-ID: <51938906.2000903@HIDDEN>
Date: Wed, 15 May 2013 15:09:26 +0200
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Michael Zucchi <notzed@HIDDEN>
Subject: Re: bug#9088: Java, JARS primary?
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
<51937710.7040703@HIDDEN>
In-Reply-To: <51937710.7040703@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org,
Automake List <automake@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
On 05/15/2013 01:52 PM, Michael Zucchi wrote:
> On 14/05/13 03:47, Stefano Lattarini wrote:
>
>> Instead, let's start implementing something *correct*, in line with
>> the Java philosophy, and with a clean API. We'll think about enhancing
>> it when (and if!) the need arise.
>
> Seems the way to go.
>
> On that, here are a few more thoughts on java's specific way of doing
> things ...
>
> files vs dirs
> --------------
>
> java projects/build systems tend to have a fairly basic mechanism to
> define the source tree(s) which would be nice to emulate, but may not
> fit well with the portability requirements of automake.
>
> They simply define the root directory and let the build system do the rest.
>
> Not necessary but would be nice. Or put another way it would basically
> suck if it required every source file to be listed explicitly and auto*
> having to be re-run every time one is added.
>
But then, how could make handle the case of generated java files? I.e.,
if half of your files are generated by (say) an awk+sed incantation,
make has to know it must build them before trying to call the java compiler.
But see below.
> In a GNU makefile I can
> just use $(shell find) (or other fancier stuff), but for automake?
>
The solution is simpler than it seems at first sight: we should just
implement the new feature in a way that can handle the use of GNU make
specific functions, without requiring too much cooperation from Automake
(that means we have to delegate most of the work at make runtime).
So, people only interested in having their Makefile work with GNU make
only will be able to use all the needed tricks with "$(shell find ...)"
or "$(wildcard ...)", while people interested in wider portability we'll
have to bite the bullet and explicitly list all their java source files.
A sort of graceful degradation.
For an example of how this approach could work, take a look at the
EXTRA_DIST support (and to the test 't/extra-dist-wildcards-gnu.sh').
> source vs data
> --------------
>
> A source tree can also include non-source data which is copied into the
> jar file verbatim at the same relative path location. At least this is
> how ant does it and given the way these resources are resolved at
> runtime makes the most sense.
>
> Again I think this needs to be specified by root directory not file. It
> could just hang off the _SOURCES or use _RESOURCES.
>
Seems reasonable.
> makefile location
> -----------------
>
> C projects often have a make file per directory, java has the build
> script at the top-level at least, outside of the source trees.
>
> This is desirable.
>
In some ways, this is desirable also for C projects actually; see the
article "Recursive Make Considered Harmful" from Peter Miller:
<http://miller.emu.id.au/pmiller/books/rmch/>
And recently, the GNU world has started moving towards making
non-recursive make-based build system a first class citizen.
For example, important GNU packages like Coreutils and Bison has
been converted to a non-recursive build system; and Automake has
been enhanced to make its use in non-recursive setups easier and
more convenient:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524>
> For the compiled code this is simple enough since the makefile will
> compile every file every time and the compiler will dump the class files
> where it's told.
>
> For the resource files the Makefile needs to resolve the resource root,
> and strip it out of the names used for the dependencies. So either it
> needs a (set of) explicit resource_root, resource_root_files variables,
> or it just needs to be defined as the root dir and handled either in the
> makefile fragment or in automake.in.
>
Doing too much pre-processing in automake.in (that is, at Automake time)
would prevent us from being able to grasp GNU make specific stuff. So
let's try to keep such pre-processing at a minimum.
> annotation processors
> ---------------------
>
> I think these can be handled by using _JAVACFLAGS or something similar.
> They can generate source for new classes at compile time, but this is
> all handled by javac in separate locations so make doesn't need to know
> about it.
>
Sounds good.
> javadoc, jni, check/test, etc
> ------------------------
>
> Some built-in support would be good. javadoc is easy, check/test should
> run junit tests I guess although i'm not too familiar with junit,
>
Or we might leave that to the use from now (they can use the 'check-local'
target), and maybe implement it in a later Automake version, once an usage
pattern has emerged (and most importantly, *if* there actually is any
request in that direction).
> jni will need some thought but should be limited in scope (support for
> javah basically, maybe not enough need to include it in automake so long as
> the dev can depend on the jar).
>
Sorry, I don't know enough on JNI to comment on this. I understand that
it is a way to include platform-specific code in a Java application, but
I have no idea how it actually work, not how much common it is.
> first cut
> ---------
>
> I've attached a pretty nasty bit of unportable makefile which attempts
> some of the above to see how it might be done.
>
Comments for that are below. I understand this is just a preliminary and
rough implementation, so please don't allow my doubts and criticism blow
your morale.
BTW, while writing this first draft, have taken into consideration all
the comments in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088>,
as well as the extensive and (AFAICS) *working* code at
<https://github.com/stumbleupon/opentsdb/blob/6059488/Makefile#L207>?
We cannot allow all those earlier thoughts and efforts go wasted ...
> Even with gnu make stuff
> it still needs some support from automake.in to handle multiple resource
> directories, and it doesn't handle everything quite properly.
>
> The build steps from this are simple:
>
> $ rm foo_jar.stamp ; make -f Auto.mak
> javac -cp lib/jjmpeg.jar:lib/test.jar -sourcepath src -d
> build/classes/foo_jar src/z/util/d.java src/z/util/c.java src/z/a.java
> src/z/b.java
> touch foo_jar.stamp
> jar cf foo.jar -C build/classes/foo_jar . \
> -C ./src ./z/util/util-names.txt \
> -C ./res ./foo.txt
> $
>
> Regards,
> Michael
> ===== Auto.mak =====
>
> # default is /usr/share/java/package ?
> jardir = $(datadir)/java/@PACKAGE@
>
Or simply '$(datadir)/java'; then we can pre-define pkgjardir
to be '$(datadir)/java/$(PACKAGE)'. Something similar is
already done for datadir, includedir, libdir, and libexecdir:
<http://www.gnu.org/software/automake/manual/automake.html#index-pkglibdir-131>
> srcdir=.
>
Just a reminder: we must also be prepared to handle VPATH builds, that
is, '$(srcdir)' != '.'; no need to think about this right away, but it
should be made to work before the feature is integrated in Automake (so
we want a design that will allow it to work!)
> all: foo.jar
>
> jar_JARS=foo.jar
>
> foo_jar_SOURCES = src
>
NAK. We should make the use list all the Java files, while (as said
before) being able to support GNU make extensions in the definition
of this variable. Unless you have strong objections to this idea;
objections which I'd like to hear ASAP.
For more complete rationales about Automake's general opposition
against the use of wildcards by default, see:
<http://www.gnu.org/software/automake/manual/automake.html#Wildcards>
> # multiple resources dirs
> foo_jar_RESOURCES = src res
>
Same rationales as above apply.
> # same as in the way one would add a in-package libtool lib, but
> # this is in the build jar path
> foo_jar_LIBADD = lib/jjmpeg.jar lib/test.jar
>
Sounds good. But maybe s/LIBADD/JARADD/?
> ## foo.jar
>
> # jar.am template, could handle multi-valued foo_jar_SOURCES
> foo_jar_SOURCES_list=$(shell cd $(srcdir) ; find $(foo_jar_SOURCES) -name '*.java')
>
This will no longer be required once $(foo_jar_SOURCES) is required
to be an explicit list.
> # automake.in generated, the find exclusions are not nearly enough to handle version control
> foo_jar_RESOURCES_list0=$(shell cd $(srcdir)/src; find . -type f -a \! -name '*.java' \! -name '*~')
> foo_jar_RESOURCES_list1=$(shell cd $(srcdir)/res; find . -type f -a \! -name '*.java' \! -name '*~')
>
Ditto, with 's/foo_jar_SOURCES/foo_jar_RESOURCES/'.
> # windows needs ;, of course ...
> # automake.in generates this from LIBADD?
>
I think it should. And of course, should allow the user
> foo_jar_CLASSPATH=lib/jjmpeg.jar:lib/test.jar
>
> foo_jar.stamp: $(foo_jar_SOURCES_list) $(foo_jar_LIBADD)
> @-rm -rf build/classes/foo_jar
>
We don't want to ignore failures here, nor to silence commands. Please
drop the leading '@-' in the line above.
> @-mkdir -p build/classes/foo_jar
>
Ditto.
In addition, "mkdir -p" is unfortunately not multithred-safe on all platforms.
We have code that should work around the issue; to take advantage of that,
just use the $(MKDIR_P) macro instead of "mkdir -p".
> javac -cp $(foo_jar_CLASSPATH) -sourcepath src -d build/classes/foo_jar $(filter %.java,$^)
>
We cannot unilaterally squat on a common file/directry name like "build"
here. No need to fix that right now though; we can easily return on the
issue later.
Also, the '$(filter %.java,$^)' is GNU make specific; it should be juse
substituted by $(foo_jar_SOURCES), no?
> touch $@
>
> foo.jar: foo_jar.stamp $(patsubst %,src/%,$(foo_jar_RESOURCES_list0)) $(patsubst %,res/%,$(foo_jar_RESOURCES_list1))
> jar cf $@ -C build/classes/foo_jar . \
> $(patsubst %,-C $(srcdir)/src %,$(foo_jar_RESOURCES_list0)) \
> $(patsubst %,-C $(srcdir)/res %,$(foo_jar_RESOURCES_list1))
>
This is too much GNU make specific. Moreover, I have zero knowledge about
how the "Java resources" are expected to work, so I don't know how to
suggest fixes or improvements. Do you have links to noob-understendable
documentation that explains in enough detail what Java resources are and
how they are suppose to work?
> .PHONY javadoc: javadoc-foo_jar
> javadoc-foo_jar:
> exit 1
> build javadoc stuff, not done yet
>
Is see that we still lack clean and installation rules. They are quite
important, and should be introduced ASAP.
Thanks, and best regards,
Stefano
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 15 May 2013 11:53:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 15 07:53:07 2013
Received: from localhost ([127.0.0.1]:45439 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UcaGY-0007sv-H0
for submit <at> debbugs.gnu.org; Wed, 15 May 2013 07:53:07 -0400
Received: from mail-pd0-f171.google.com ([209.85.192.171]:55749)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <notzed@HIDDEN>) id 1UcaGV-0007sP-PC
for 9088 <at> debbugs.gnu.org; Wed, 15 May 2013 07:53:05 -0400
Received: by mail-pd0-f171.google.com with SMTP id r11so1305914pdi.2
for <9088 <at> debbugs.gnu.org>; Wed, 15 May 2013 04:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:cc
:subject:references:in-reply-to:x-enigmail-version:content-type;
bh=mDwsU0Xn9l9wpzLIRJu312/smutJh+kk22eCgUTfLfM=;
b=fAuu5i257hrSdRBgnH2EarmOJHW3SLtTX4Gk9PRdvf1fWSNB0Is02c4OLcN28AvEAA
tCBHAQ8tfzC/j7qT9qT8SQgO5TLIGU0FomKy1VcnwHKCyxWs+YGoImWhwI5fW1W3dWhK
MIg3dci0blYPurjwfadnH9XHa+/Bl2d9ffMZVvi4xXeyM643OiEDuhp98MiPXSBmLN/Z
JM8KtH1P71xAhwT/DZToR7AXsFMntHPoUXBxMqZowTnNzIjjPaGMZsDmmJFzqVSaQd01
cCTUtKgKbuyQQw5uIRWWpYZB+h0eiv7aFRj7LAMCXEq9yhqSFAIn4yESUNFbZHpvMuQ5
OGCg==
X-Received: by 10.66.121.108 with SMTP id lj12mr35978488pab.51.1368618773681;
Wed, 15 May 2013 04:52:53 -0700 (PDT)
Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net.
[121.45.44.8])
by mx.google.com with ESMTPSA id gi2sm2602329pbb.2.2013.05.15.04.52.50
for <multiple recipients>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 15 May 2013 04:52:52 -0700 (PDT)
Message-ID: <51937710.7040703@HIDDEN>
Date: Wed, 15 May 2013 21:22:48 +0930
From: Michael Zucchi <notzed@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: bug#9088: Java, JARS primary?
References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN>
<518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN>
<519073BC.5020104@HIDDEN> <51912E22.3040604@HIDDEN>
In-Reply-To: <51912E22.3040604@HIDDEN>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/mixed; boundary="------------030000020502070308000700"
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: 9088
Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.9 (-)
This is a multi-part message in MIME format.
--------------030000020502070308000700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 14/05/13 03:47, Stefano Lattarini wrote:
> Instead, let's start implementing something *correct*, in line with
> the Java philosophy, and with a clean API. We'll think about enhancing
> it when (and if!) the need arise.
Seems the way to go.
On that, here are a few more thoughts on java's specific way of doing
things ...
files vs dirs
--------------
java projects/build systems tend to have a fairly basic mechanism to
define the source tree(s) which would be nice to emulate, but may not
fit well with the portability requirements of automake.
They simply define the root directory and let the build system do the rest.
Not necessary but would be nice. Or put another way it would basically
suck if it required every source file to be listed explicitly and auto*
having to be re-run every time one is added. In a GNU makefile I can
just use $(shell find) (or other fancier stuff), but for automake?
source vs data
--------------
A source tree can also include non-source data which is copied into the
jar file verbatim at the same relative path location. At least this is
how ant does it and given the way these resources are resolved at
runtime makes the most sense.
Again I think this needs to be specified by root directory not file. It
could just hang off the _SOURCES or use _RESOURCES.
makefile location
-----------------
C projects often have a make file per directory, java has the build
script at the top-level at least, outside of the source trees.
This is desirable.
For the compiled code this is simple enough since the makefile will
compile every file every time and the compiler will dump the class files
where it's told.
For the resource files the Makefile needs to resolve the resource root,
and strip it out of the names used for the dependencies. So either it
needs a (set of) explicit resource_root, resource_root_files variables,
or it just needs to be defined as the root dir and handled either in the
makefile fragment or in automake.in.
annotation processors
---------------------
I think these can be handled by using _JAVACFLAGS or something similar.
They can generate source for new classes at compile time, but this is
all handled by javac in separate locations so make doesn't need to know
about it.
javadoc, jni, check/test, etc
------------------------
Some built-in support would be good. javadoc is easy, check/test should
run junit tests I guess although i'm not too familiar with junit, jni
will need some thought but should be limited in scope (support for javah
basically, maybe not enough need to include it in automake so long as
the dev can depend on the jar).
first cut
---------
I've attached a pretty nasty bit of unportable makefile which attempts
some of the above to see how it might be done. Even with gnu make stuff
it still needs some support from automake.in to handle multiple resource
directories, and it doesn't handle everything quite properly.
The build steps from this are simple:
$ rm foo_jar.stamp ; make -f Auto.mak
javac -cp lib/jjmpeg.jar:lib/test.jar -sourcepath src -d
build/classes/foo_jar src/z/util/d.java src/z/util/c.java src/z/a.java
src/z/b.java
touch foo_jar.stamp
jar cf foo.jar -C build/classes/foo_jar . \
-C ./src ./z/util/util-names.txt \
-C ./res ./foo.txt
$
Regards,
Michael
--------------030000020502070308000700
Content-Type: text/plain;
name="Auto.mak"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Auto.mak"
# default is /usr/share/java/package ?
jardir = $(datadir)/java/@PACKAGE@
srcdir=.
all: foo.jar
jar_JARS=foo.jar
foo_jar_SOURCES = src
# multiple resources dirs
foo_jar_RESOURCES = src res
# same as in the way one would add a in-package libtool lib, but this is in the build jar path
foo_jar_LIBADD = lib/jjmpeg.jar lib/test.jar
## foo.jar
# jar.am template, could handle multi-valued foo_jar_SOURCES
foo_jar_SOURCES_list=$(shell cd $(srcdir) ; find $(foo_jar_SOURCES) -name '*.java')
# automake.in generated, the find exclusions are not nearly enough to handle version control
foo_jar_RESOURCES_list0=$(shell cd $(srcdir)/src; find . -type f -a \! -name '*.java' \! -name '*~')
foo_jar_RESOURCES_list1=$(shell cd $(srcdir)/res; find . -type f -a \! -name '*.java' \! -name '*~')
# windows needs ;, of course ...
# automake.in generates this from LIBADD?
foo_jar_CLASSPATH=lib/jjmpeg.jar:lib/test.jar
foo_jar.stamp: $(foo_jar_SOURCES_list) $(foo_jar_LIBADD)
@-rm -rf build/classes/foo_jar
@-mkdir -p build/classes/foo_jar
javac -cp $(foo_jar_CLASSPATH) -sourcepath src -d build/classes/foo_jar $(filter %.java,$^)
touch $@
foo.jar: foo_jar.stamp $(patsubst %,src/%,$(foo_jar_RESOURCES_list0)) $(patsubst %,res/%,$(foo_jar_RESOURCES_list1))
jar cf $@ -C build/classes/foo_jar . \
$(patsubst %,-C $(srcdir)/src %,$(foo_jar_RESOURCES_list0)) \
$(patsubst %,-C $(srcdir)/res %,$(foo_jar_RESOURCES_list1))
.PHONY javadoc: javadoc-foo_jar
javadoc-foo_jar:
exit 1
build javadoc stuff, not done yet
--------------030000020502070308000700--
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 13 May 2013 18:17:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 13 14:17:39 2013 Received: from localhost ([127.0.0.1]:38940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UbxJb-0005XW-HI for submit <at> debbugs.gnu.org; Mon, 13 May 2013 14:17:39 -0400 Received: from mail-ea0-f174.google.com ([209.85.215.174]:62864) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1UbxJa-0005XO-1z for 9088 <at> debbugs.gnu.org; Mon, 13 May 2013 14:17:38 -0400 Received: by mail-ea0-f174.google.com with SMTP id z7so2744568eaf.5 for <9088 <at> debbugs.gnu.org>; Mon, 13 May 2013 11:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mTXoX6nywvhmbuppAVz9w7AUeoJNulkR6qRkfbmcjdA=; b=ISBFx2QO8anzKokkc3odUxPbl4BwwKC9cZLVsgLosJQ2SVBfyR7clOVlLrMdatoic7 /xN1Mrjw1JzZGDjIh+99f2X2HOypFoMxf4s2JyK6vhYfcWGPz0D0OeV7Ur0hyz3/82Yi O6I2BzvKC9g4h6sBTYlTquhB+ZfyBdPWChSbE/Q/K9PPH17C88x/iLx75o+XNdvf8QW2 U6yKopAqG66cjFYmGYbmQ97b4bTACErOKMxbKYkfSuQnnELLmu9Ok7kx2QimA/MbmMGH UGDIlquMpF4koBrd28ViWOVDKvbCvxJJUqR7f3UOipPN0Ns5bjIIZ5hRsc/R7hvyzS4p WfTQ== X-Received: by 10.14.179.133 with SMTP id h5mr81573844eem.34.1368469028901; Mon, 13 May 2013 11:17:08 -0700 (PDT) Received: from [192.168.178.20] (host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93]) by mx.google.com with ESMTPSA id y10sm24626852eev.3.2013.05.13.11.17.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 11:17:08 -0700 (PDT) Message-ID: <51912E22.3040604@HIDDEN> Date: Mon, 13 May 2013 20:17:06 +0200 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Michael Zucchi <notzed@HIDDEN> Subject: Re: bug#9088: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> <518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN> <519073BC.5020104@HIDDEN> In-Reply-To: <519073BC.5020104@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 9088 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) Given all the rationales given by Russ and Micheal, I think we should drop the idea of having "smart dependencies" for the moment being (I suggested that because, in my ignorance of Java, I thought they would be easy to implement). Instead, let's start implementing something *correct*, in line with the Java philosophy, and with a clean API. We'll think about enhancing it when (and if!) the need arise. Thanks, Stefano
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 13 May 2013 05:02:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 13 01:02:21 2013 Received: from localhost ([127.0.0.1]:38003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Ubktw-0004LE-M2 for submit <at> debbugs.gnu.org; Mon, 13 May 2013 01:02:21 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:42986) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <notzed@HIDDEN>) id 1Ubktt-0004L5-TD for 9088 <at> debbugs.gnu.org; Mon, 13 May 2013 01:02:19 -0400 Received: by mail-pa0-f42.google.com with SMTP id bj3so4320758pad.15 for <9088 <at> debbugs.gnu.org>; Sun, 12 May 2013 22:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=pp3liy94e3G8b/2xCppCauvkygM5s/sore3oN+gew3s=; b=Ek4KXIdsyXrEjOonRQ6Y05qpmjjD7rI9nfg4y0E9lpJd34iN6F2AraQGcrXUW5s/4B m0by31TDxT6XHAceGp/IGe0zxpPKvYyRjdb270p9ROwh+bDK72iRgg/84nX2uUNh9RXB rIKFD7HEqdnVJnCYCc21C/h+pdu4LLsFnLphXeJ12d1PsZ8pLTPHPkUltjsZR8KyxrAz gzy+Fs4/JfKqrXYRd2TNmyzuJie9oJzFlxTuiSO1KooL7lpbAbqHGZuh8SqeDEbvQCKk DdAiaqLCsaWwEkXiEgNbPsxgauQJOnFkeRvBl3dWDZjcKygv9NFYww4SeIOmxIcEPGVZ E7Vw== X-Received: by 10.68.108.196 with SMTP id hm4mr27764559pbb.88.1368421312108; Sun, 12 May 2013 22:01:52 -0700 (PDT) Received: from [192.168.1.6] (ppp121-45-44-8.lns20.adl2.internode.on.net. [121.45.44.8]) by mx.google.com with ESMTPSA id iy2sm12458428pbb.31.2013.05.12.22.01.49 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 22:01:51 -0700 (PDT) Message-ID: <519073BC.5020104@HIDDEN> Date: Mon, 13 May 2013 14:31:48 +0930 From: Michael Zucchi <notzed@HIDDEN> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: bug#9088: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> <518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN> In-Reply-To: <518FCA35.2030506@HIDDEN> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 9088 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) On 13/05/13 02:28, Stefano Lattarini wrote: > On 05/12/2013 06:29 AM, Michael Zucchi wrote: >> Using $? will not suffice as a dependency check, as it's trivially easy >> to create an example which will compile ok after a change but create a >> broken jar. e.g. add a new abstract method to an abstract class but >> forget to fix all sub-classes. >> > I don't really follow here, sorry (likely because I know almost nothing > about Java). Do you mean that, if you have a bunch of .java files that > get compiled into a single jar, and you change just one of these files, > you also need to recompile all the other ones in order not to risk ending > up with a broken and/or inconsistent jar? If it is so, that's awful :-( Well if you were only going on the timestamps of the changed files it would not work. I'm not sure it's really that awful - it's done in C because that's how C is compiled, and compilation is so slow. If it was made fast enough the need for all the considerable complexity of creating and managing dependencies would go away. For a point of reference with a small library i have, a build of 104 java files with 22KLOC takes under 3s on my workstation. Building them "one source file at a time" (see next quoted block) takes about a minute. For big projects code that doesn't change often can be placed in it's own jar negating the need to rebuild that part every time downstream code changes - although one does have to rebuild everything downstream when that jar does. Hmm, now i think about it there is a possible solution to the dependency problem but i'm not sure it's worth it and it has some caveats. The main one being that stale classes could still make it to the jar (so you would have to manually make clean before make install), and it also needs a dependency tool. Because of the strict rules on java package names (they must match the directory they file is in), the import statements could be used to generate some coarse-but-accurate dependencies. As anything in the same package does not need an import statement, one would have to assume every class in the same package is included (i.e. ostensibly the same directory, but it may span multiple trees). Actually it isn't quite that simple - as you can just use fully qualified names without any import statement, so the dependency tool would have to scan the whole file. However, assuming these coarse dependencies could be generated reliably ... the following might work. Lets say the project is something like src/z/a.java imports c src/z/b.java src/z/util/c.java src/z/util/d.java A deps file is created with the cross dependencies for each file. It is simply everything in the same package, and then everything within the project that a given file imports. the deps file: src/z/a.java src/z/b.java src/z/a.java src/z/util/c.java src/z/util/c.java src/z/util/d.java i.e. src/z/*.java, src/z/utill/*.java, then dependencies for any files the Makefile: # this is so plain package names can be used VPATH=src JAVASRC=z/a.java z/b.java z/util/c.java z/util/d.java all: z.jar build.stamp: $(JAVASRC) @-mkdir classes @-rm buildsrc for n in $? ; do grep $$n deps >> buildsrc ; done javac -sourcepath src -d classes @buildsrc touch build.stamp rm buildsrc # just classes - in reality it needs to deal with other files z.jar: build.stamp jar cf $@ -C classes . So it takes the modified list of files and expands it to include any forward requirements. So for example, touch src/z/util/c.java will rebuild a, c, and d - all the classes which might possibly have something to with c. This simple example has some bugs in that it might over-build (e.g. touch a.java will build a, b as required but also c which is not) but that is fixable. Given the caveats, is it worth it? >> So without compiler support for dependency generation I think the only >> practical solution will be to build all files every time. Even the >> sub-directory holding the classes will probably need to be wiped away >> otherwise the jar could contain extraneous classes no longer generated >> from the corresponding source which would probably not be a good thing. > Couldn't we put the *.class files obtained compiling a foo.java file > into a (say) 'foo.d' directory, and remove & rebuild only that directory > whenever foo.java changes? You would have to then invoke the compiler individually on each file, which is at least 1-3 orders of magnitude slower than just compiling every file at the same time. And it wouldn't have the desired result anyway, if it can't find any required .class files it finds the corresponding source and builds them into the target location as well so then build order becomes an issue. I can go into more detail if you like ... One might ask why use make then, but there is more to real projects than a bunch of java source files that need compiling. Michael
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 12 May 2013 20:50:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 12 16:50:30 2013 Received: from localhost ([127.0.0.1]:37815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UbdDy-0001Y0-Di for submit <at> debbugs.gnu.org; Sun, 12 May 2013 16:50:30 -0400 Received: from smtp1.stanford.edu ([171.67.219.81]:42125 helo=smtp.stanford.edu) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <rra@HIDDEN>) id 1UbdDu-0001Xj-O8 for 9088 <at> debbugs.gnu.org; Sun, 12 May 2013 16:50:28 -0400 Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 70BCB142569; Sun, 12 May 2013 13:50:02 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 87F6D142555; Sun, 12 May 2013 13:50:01 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 54E0725782; Sun, 12 May 2013 13:50:00 -0700 (PDT) From: Russ Allbery <rra@HIDDEN> To: Michael Zucchi <notzed@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN Subject: Re: bug#9088: Java, JARS primary? In-Reply-To: <518FCA35.2030506@HIDDEN> (Stefano Lattarini's message of "Sun, 12 May 2013 18:58:29 +0200") Organization: The Eyrie References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> <518F1A8C.7040702@HIDDEN> <518FCA35.2030506@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Sun, 12 May 2013 13:50:00 -0700 Message-ID: <87ppwv53ev.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 9088 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.2 (---) Stefano Lattarini <stefano.lattarini@HIDDEN> writes: > On 05/12/2013 06:29 AM, Michael Zucchi wrote: >> Hi again, >> >> I (mostly) just have an observation to add to the bug tracker discussion >> on the dependency generation. >> >> Using $? will not suffice as a dependency check, as it's trivially easy >> to create an example which will compile ok after a change but create a >> broken jar. e.g. add a new abstract method to an abstract class but >> forget to fix all sub-classes. > I don't really follow here, sorry (likely because I know almost nothing > about Java). Do you mean that, if you have a bunch of .java files that > get compiled into a single jar, and you change just one of these files, > you also need to recompile all the other ones in order not to risk ending > up with a broken and/or inconsistent jar? If it is so, that's awful :-( Think of it like changing a header file in C to change the definition of a struct. If you don't recompile all of the C source that references that struct, you get broken code. The same thing is true in Java, except that Java doesn't have separate files for interfaces versus implementations (or at least doesn't mandate it; that's a coding style that some people use and other people don't). Java development environments like Eclipse figure out the necessary dependencies and know what *.java files need to be recompiled to pick up changes (and detect errors). If one is using a command-line compiler that can't generate similar sorts of dependency information, it's usually best to just rebuild all the *.java files that make up a JAR if any of them have changed, to ensure that no errors have been introduced and no internal APIs have changed. -- Russ Allbery (rra@HIDDEN) <http://www.eyrie.org/~eagle/>
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 12 May 2013 16:59:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 12 12:59:10 2013 Received: from localhost ([127.0.0.1]:37663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UbZc6-0001U1-GW for submit <at> debbugs.gnu.org; Sun, 12 May 2013 12:59:10 -0400 Received: from mail-we0-f175.google.com ([74.125.82.175]:49807) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1UbZc4-0001Tr-5R for 9088 <at> debbugs.gnu.org; Sun, 12 May 2013 12:59:09 -0400 Received: by mail-we0-f175.google.com with SMTP id p57so5544277wes.20 for <9088 <at> debbugs.gnu.org>; Sun, 12 May 2013 09:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=v70fnBTrnzkR0KgjH7AIZPDxO+saQUi8dVHeUajLPY0=; b=Hj5ECx5+rjIcxkMcZ8Sc8JwKxuNuSOD7OOyTz5QcsPk+yZqfDVzdssuvAo07tJGgAo hgqpjgzpsfETWuaESS72lGHLjVd78dzNfhSqHPrw6vtfSdhqs9caX+RjFLuZKwY0mC2G wAyF63sXNILLXzswn9X610leGCEvqsbYgZLS3yvLJMhbNBbBtpNUHIjg2wXOWCpBSih1 5HIf9DcrszGib9C+xbmvEde3zI7TmJ7xJ3nXoJG8S8XyLEHvvuGI4rQT840relBoPFxA RUHMDA/J2VvMexKbcVibOUl6XZTkHXqyKmIAiygquho7qb7YyM2aGT89y3NL9eLnRn4q GaHg== X-Received: by 10.181.12.1 with SMTP id em1mr14020158wid.4.1368377925082; Sun, 12 May 2013 09:58:45 -0700 (PDT) Received: from [192.168.178.20] (host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93]) by mx.google.com with ESMTPSA id bs20sm10507908wib.0.2013.05.12.09.58.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 09:58:41 -0700 (PDT) Message-ID: <518FCA35.2030506@HIDDEN> Date: Sun, 12 May 2013 18:58:29 +0200 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Michael Zucchi <notzed@HIDDEN> Subject: Re: bug#9088: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> <518F1A8C.7040702@HIDDEN> In-Reply-To: <518F1A8C.7040702@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9088 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) On 05/12/2013 06:29 AM, Michael Zucchi wrote: > Hi again, > > I (mostly) just have an observation to add to the bug tracker discussion > on the dependency generation. > > Using $? will not suffice as a dependency check, as it's trivially easy > to create an example which will compile ok after a change but create a > broken jar. e.g. add a new abstract method to an abstract class but > forget to fix all sub-classes. > I don't really follow here, sorry (likely because I know almost nothing about Java). Do you mean that, if you have a bunch of .java files that get compiled into a single jar, and you change just one of these files, you also need to recompile all the other ones in order not to risk ending up with a broken and/or inconsistent jar? If it is so, that's awful :-( > So without compiler support for dependency generation I think the only > practical solution will be to build all files every time. Even the > sub-directory holding the classes will probably need to be wiped away > otherwise the jar could contain extraneous classes no longer generated > from the corresponding source which would probably not be a good thing. > Couldn't we put the *.class files obtained compiling a foo.java file into a (say) 'foo.d' directory, and remove & rebuild only that directory whenever foo.java changes? > I have had a bit of a look at automake.in and some of the .am files - it > seems to me it would not be any use using the existing in built language > code as that is designed for 1:1 source:object compilation. > Maybe we can steal some code from the existing _JAVA primary though, were that makes sense? > But before I get too bogged down in that I think I will first try to > create a simple Makefile with the required features for discussion, and > then worry about how to generate it. > This is the sanest approach, yes. You might also write some tests on the expected behaviours of this Makefile, and we could later re-use them in our testsuite. > Most of it should be straightforward apart from deciding on conventions. > > Regards, > Michael > Thanks, Stefano
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 12 May 2013 04:29:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 12 00:29:28 2013 Received: from localhost ([127.0.0.1]:37069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UbNuZ-0004Gj-W7 for submit <at> debbugs.gnu.org; Sun, 12 May 2013 00:29:28 -0400 Received: from mail-pb0-f47.google.com ([209.85.160.47]:46686) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <notzed@HIDDEN>) id 1UbNuX-0004GM-0r for 9088 <at> debbugs.gnu.org; Sun, 12 May 2013 00:29:25 -0400 Received: by mail-pb0-f47.google.com with SMTP id rr4so391274pbb.20 for <9088 <at> debbugs.gnu.org>; Sat, 11 May 2013 21:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=dSbz8XPghQsZ1D3Gz/l96EiBBfDxsvx6dG6f9nBbl2g=; b=rgcCTFFfzk0IsDppSU+sJ/fSlK+jGcKzN4BtzhRY8qsfwq/dse7TRrI64jWjaBVnM5 l1Z3UQwr5uVMpMXqUp/cOYHbVIRXU1mIQUnYQp44qaZQ2tZWHVCdUBlnJ2xgpPz6LVOn j0Zn+AHnzhUFn+0OuvdD5zLkiDk/LAaVVJ0XrWWqZyj8baF7e12RZfbnWIMJHEExQ/Ya y3EzrwVccg6EtJJLNEzTbDmYUrHwIAalfEiIyC5YaYyZko7+Kdl3VAwO5PEaeXE8yV3L qdgiVr35UlEl1WVHLkVkAO1EP3hK5bkFdM/HH1WAoUjhG1aqxM2h3Nbu+lozUrO0xP+N U1nw== X-Received: by 10.66.144.170 with SMTP id sn10mr24174371pab.42.1368332944364; Sat, 11 May 2013 21:29:04 -0700 (PDT) Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net. [121.45.44.8]) by mx.google.com with ESMTPSA id xl10sm9322511pac.15.2013.05.11.21.29.02 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 11 May 2013 21:29:03 -0700 (PDT) Message-ID: <518F1A8C.7040702@HIDDEN> Date: Sun, 12 May 2013 13:59:00 +0930 From: Michael Zucchi <notzed@HIDDEN> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> In-Reply-To: <518CEC05.7020502@HIDDEN> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 9088 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi again, I (mostly) just have an observation to add to the bug tracker discussion on the dependency generation. Using $? will not suffice as a dependency check, as it's trivially easy to create an example which will compile ok after a change but create a broken jar. e.g. add a new abstract method to an abstract class but forget to fix all sub-classes. So without compiler support for dependency generation I think the only practical solution will be to build all files every time. Even the sub-directory holding the classes will probably need to be wiped away otherwise the jar could contain extraneous classes no longer generated from the corresponding source which would probably not be a good thing. I have had a bit of a look at automake.in and some of the .am files - it seems to me it would not be any use using the existing in built language code as that is designed for 1:1 source:object compilation. But before I get too bogged down in that I think I will first try to create a simple Makefile with the required features for discussion, and then worry about how to generate it. Most of it should be straightforward apart from deciding on conventions. Regards, Michael
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 11 May 2013 02:30:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 10 22:30:59 2013 Received: from localhost ([127.0.0.1]:36067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1UazaK-0007ho-BT for submit <at> debbugs.gnu.org; Fri, 10 May 2013 22:30:58 -0400 Received: from mail-da0-f48.google.com ([209.85.210.48]:46770) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <notzed@HIDDEN>) id 1UazYb-0007aF-8U for 9088 <at> debbugs.gnu.org; Fri, 10 May 2013 22:29:10 -0400 Received: by mail-da0-f48.google.com with SMTP id h32so1273307dak.35 for <9088 <at> debbugs.gnu.org>; Fri, 10 May 2013 19:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=NPddjiEPYXsjoMY1v/WZOeVIIOuRr6v53lYIdpm018M=; b=SFZfVyWHY/Qsh0QX0nkcK+I+Q2ShcbA+4/qxGzSpJiKJXQEsgh0tpelP5aMGvTX54v zc89MYabeMYsI7pZecGUw/o5L175DtZyo+Vkod5h2Hg9Skcn0Dih6tcJ1R25Sb5xRmTq /BOSxIV8lwghm9Drko22HRjX0Dx903jVUnmSXOl/HiDTdbouNVtJFKUiI9ktta1fIADJ ARNqBxWe9tjY63khVGzl2wmjXo/Sta/786LzDBZz0aC08+SOSS9nig0OImaaqnl0Vzp3 L78wSre05jy7aFkSKn3UoICt1oCF20Ng6sBTV8/LrHGRadYsnrHWaMEP4SveQ8Mz3Zyt tE5w== X-Received: by 10.68.171.226 with SMTP id ax2mr4107778pbc.201.1368239335058; Fri, 10 May 2013 19:28:55 -0700 (PDT) Received: from [192.168.1.7] (ppp121-45-44-8.lns20.adl2.internode.on.net. [121.45.44.8]) by mx.google.com with ESMTPSA id tq8sm4656030pbc.30.2013.05.10.19.28.52 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 May 2013 19:28:54 -0700 (PDT) Message-ID: <518DACE3.9020401@HIDDEN> Date: Sat, 11 May 2013 11:58:51 +0930 From: Michael Zucchi <notzed@HIDDEN> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: Java, JARS primary? References: <518A2434.4040702@HIDDEN> <518CEC05.7020502@HIDDEN> In-Reply-To: <518CEC05.7020502@HIDDEN> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 9088 X-Mailman-Approved-At: Fri, 10 May 2013 22:30:49 -0400 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Stefano, On 10/05/13 22:15, Stefano Lattarini wrote: > So, if you are willing to go ahead, you might want to clone the Automake > git repository, read the HACKING file, and start perusing the files > 'bin/automake.in' and 'lib/am/*.am' for "inspiration". Thanks for all this information. I write perl like I write C, but i've been using it occasionally for nearly 20 years so there's some hope :) I think I will have to have a bit of a poke around before I can contribute anything meaningful to a discussion on the details. To start with i'll just look at the current suggestions on the bug. In the event I can't get anywhere I will also let you and the list know i've given up and not leave it dangling. Cheers, Michael
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at 9088) by debbugs.gnu.org; 10 May 2013 12:46:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 10 08:46:15 2013
Received: from localhost ([127.0.0.1]:35426 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1UamiF-0000Fu-30
for submit <at> debbugs.gnu.org; Fri, 10 May 2013 08:46:15 -0400
Received: from mail-ea0-f173.google.com ([209.85.215.173]:32848)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1UamiB-0000FD-Il
for 9088 <at> debbugs.gnu.org; Fri, 10 May 2013 08:46:13 -0400
Received: by mail-ea0-f173.google.com with SMTP id d10so2249602eaj.32
for <9088 <at> debbugs.gnu.org>; Fri, 10 May 2013 05:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type;
bh=8Lmnc/L5lQHW/iqQjsnhzDvzY8Qd0b7u6IrAhOuCQnY=;
b=wySaTDf1ZR+f5DdZTvZJhS3uQI5c/au+MrG49PhxwJ0SpI8295XTGRv+3muDBviCRj
xnVz4wBJy6yqD0cSJLQxgl9pLOT2chncRyoVVtiXQmR2QBsR/JdgzCz4BhxkP6j45yHu
TgD52QHT0Zxkap5CkFJjfzGf2ZDWr7krrCLbmJWIcBYxrTzdb4qzEJBlMIMTEljY7YLh
3a8vVoQXIzhHsLirmLO8Pl9oE2+n9A4vvX/dU0/fuIxn6TSNwftioqc7U48c5gGj/qKx
Ym8zt2BFIHRoym7Z4KTCIoy4YkRUcME4rjRUeEAODMPl/H5oKyiBRK0aZoTgwmyWqe6l
hJOg==
X-Received: by 10.14.202.201 with SMTP id d49mr41466326eeo.1.1368189960450;
Fri, 10 May 2013 05:46:00 -0700 (PDT)
Received: from [192.168.178.20]
(host93-95-dynamic.6-79-r.retail.telecomitalia.it. [79.6.95.93])
by mx.google.com with ESMTPSA id q1sm3390709eez.6.2013.05.10.05.45.58
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 10 May 2013 05:45:59 -0700 (PDT)
Message-ID: <518CEC05.7020502@HIDDEN>
Date: Fri, 10 May 2013 14:45:57 +0200
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Michael Zucchi <notzed@HIDDEN>
Subject: Re: Java, JARS primary?
References: <518A2434.4040702@HIDDEN>
In-Reply-To: <518A2434.4040702@HIDDEN>
Content-Type: multipart/mixed; boundary="------------090702000309080103000607"
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 9088
Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
This is a multi-part message in MIME format.
--------------090702000309080103000607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
[+cc bug#9088]
On 05/08/2013 12:08 PM, Michael Zucchi wrote:
>
> Hi list,
>
> I recently added a tiny bit of java+jni to an auto* configured project,
> and during the process came across some discussion from about two years
> ago about improving Java support. As documented on:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088
>
I'm adding that in CC:, so that this new discussion will get correctly
registered in the bug tracker.
> So, it seems the JAVA deprecation was carried out,
>
Actually, not really. But I see the documentation mistakenly report
such a deprecation in pretty strong terms. The attached patch fixes
that (and adds you to the THANKS file).
> but not the JARS
> implementation. I presume that was mainly due to lack of interest
> together with critical-path personnel constraints?
>
Basically, yes. If somebody knowledgeable enough were to write patches,
they would likely be gladly received. Of course, there is not need to
present complete patches right away; the best thing to do is start with
some RFC version to spark a discussion, and then refine/extended them
as needed --- and this is where the community should provide help and
feedback to the patch writer.
> Unfortunately as
> much as ant (really) sucks, I can't see the Java world changing it's use
> of horrid tools, and the GNU world still seems to shun Java too - so
> interest may never pick up.
>
> However, assuming it hasn't gone anywhere beyond that bug report,
>
It hasn't, sadly.
> where
> would one begin were one to try to tackle this? m4 mostly just gives me
> the willies so i'm not sure I can help much but if I waste my time it's
> only my time wasted.
>
m4 is only required in order to write configure tests. For this new feature,
doing that might be trivial, and needn't be done right away: you could just
write the first version of the patches assuming java and jar are present,
and follow-up patches might improve on that writing proper configure tests.
The real workhorses here are the automake script (~ 8000 lines of perl), and
the *.am Makefile fragments in the 'lib/am' subdirectory. That's what you'll
need to interact with.
So, if you are willing to go ahead, you might want to clone the Automake
git repository, read the HACKING file, and start perusing the files
'bin/automake.in' and 'lib/am/*.am' for "inspiration".
Also, notice that in order to have any non-trivial change integrated in the
official Automake repository, you'll need to either assign copyright for the
change to the Free Software Foundation, or at least explicitly put it in the
public domain. If you are willing to proceed, contact me off-list, and I'll
try to help about this issue.
Thanks, and best regards,
Stefano
--------------090702000309080103000607
Content-Type: text/x-patch;
name="0001-docs-we-still-don-t-have-the-promised-better-Java-in.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-docs-we-still-don-t-have-the-promised-better-Java-in.pa";
filename*1="tch"
From 4ccf9a8034c597f33ce9592f06533e3cd096fd99 Mon Sep 17 00:00:00 2001
Message-Id: <4ccf9a8034c597f33ce9592f06533e3cd096fd99.1368124506.git.stefano.lattarini@HIDDEN>
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
Date: Thu, 9 May 2013 20:23:40 +0200
Subject: [PATCH] docs: we still don't have the promised better Java interface
Reported by Michael Zucchi:
<http://lists.gnu.org/archive/html/automake/2013-05/threads.html>
See also automake bug#9088.
* doc/automake.texi (Java): Adjust and clarify.
* THANKS: Update.
Reported-by: Michael Zucchi <notzed@HIDDEN>
Signed-off-by: Stefano Lattarini <stefano.lattarini@HIDDEN>
---
THANKS | 1 +
doc/automake.texi | 8 ++++----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/THANKS b/THANKS
index fd023e2..66b3270 100644
--- a/THANKS
+++ b/THANKS
@@ -261,6 +261,7 @@ Michael Brantley Michael-Brantley@HIDDEN
Michael Daniels mdaniels@HIDDEN
Michael Hofmann mhofma@HIDDEN
Michael Ploujnikov ploujj@HIDDEN
+Michael Zucchi notzed@HIDDEN
Michel de Ruiter mdruiter@HIDDEN
Mike Castle dalgoda@HIDDEN
Mike Frysinger vapier@HIDDEN
diff --git a/doc/automake.texi b/doc/automake.texi
index e52cc3a..58561ed 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7598,11 +7598,11 @@ libtool, The Libtool Manual}) with the @code{LTLIBRARIES} primary.
Automake provides some minimal support for Java bytecode compilation with
the @code{JAVA} primary (in addition to the support for compiling Java to
native machine code; @pxref{Java Support with gcj}). Note however that
-@emph{the interface and most features described here are deprecated}; the
-next automake release will strive to provide a better and cleaner
+@emph{the interface and most features described here are deprecated}.
+Future Automake releases will strive to provide a better and cleaner
interface, which however @emph{won't be backward-compatible}; the present
-interface will probably be removed altogether in future automake releases
-(1.13 or later), so don't use it in new code.
+interface will probably be removed altogether some time after the
+introduction of the new interface (if that ever materializes).
Any @file{.java} files listed in a @code{_JAVA} variable will be
compiled with @code{JAVAC} at build time. By default, @file{.java}
--
1.8.3.rc0.19.g7e6a0cc
--------------090702000309080103000607--
bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 2 Aug 2011 16:06:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 02 12:06:24 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QoHU8-0002qf-BV for submit <at> debbugs.gnu.org; Tue, 02 Aug 2011 12:06:24 -0400 Received: from mail-yi0-f44.google.com ([209.85.218.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <tsunanet@HIDDEN>) id 1QoHU6-0002qX-1B for 9088 <at> debbugs.gnu.org; Tue, 02 Aug 2011 12:06:23 -0400 Received: by yie30 with SMTP id 30so4175883yie.3 for <9088 <at> debbugs.gnu.org>; Tue, 02 Aug 2011 09:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3Q1miQ+8bumXKWuVUn0lOjtQFuKEqi0P6S6olhDHEsw=; b=AuHRfeG0XsFegxFvrcxRw8OwVP0tBlKmsW8mqVMcplCeP0Cy+T+vo2JWlymALZxAso URGKd71gzh2b8xRa5hzEmXQkE+Kxku5Xz1C/3PorORm5DmMh4zOFKtqM8fCK5BMWYoKZ k60xdboJp5yFF9dLpwS+uz/Yy2YEAABxkWtZw= Received: by 10.146.230.39 with SMTP id c39mr4109792yah.27.1312301152773; Tue, 02 Aug 2011 09:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.167.4 with HTTP; Tue, 2 Aug 2011 09:05:32 -0700 (PDT) In-Reply-To: <CAF1jjLvqU_+Mf=82hpj_uQQh_BmPEoGXcGXM=7BVOKeEgCCoSQ@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <20110718062030.325920@HIDDEN> <CAFKYj4d54EoAq-z2fpwCy+uCGREVkaQeRmo=Q++o04+5dzAEaQ@HIDDEN> <CAF1jjLvqU_+Mf=82hpj_uQQh_BmPEoGXcGXM=7BVOKeEgCCoSQ@HIDDEN> From: tsuna <tsunanet@HIDDEN> Date: Tue, 2 Aug 2011 09:05:32 -0700 Message-ID: <CAFKYj4f7BZB8d433tiLf+mrd3+toNdqOsCJCp3dzXuZVr1L1hg@HIDDEN> Subject: Re: bug#9088: Java support To: NightStrike <nightstrike@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: 9088 Cc: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.9 (---) On Wed, Jul 27, 2011 at 9:00 AM, NightStrike <nightstrike@HIDDEN> wrote: > On Wed, Jul 20, 2011 at 1:04 AM, tsuna <tsunanet@HIDDEN> wrote: >> What would be nice would be to have the ability to recompile only the >> .java that changed. =A0So when you edit 2/3 files, then we'd build just >> that, but in one command. > > make can handle this pretty well. =A0If all the source files are listed > as prerequisites, $? will list all the ones newer than the target. > So, automake could easily write a rule to run the compiler against > only the .java files that have changed. Haha, I had forgotten about $? http://www.gnu.org/software/make/manual/make.html#index-g_t_0024_003f-944 Seems like $? is portable, I wonder why I never used it much. Thanks for the pointer. --=20 Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 27 Jul 2011 19:09:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 27 15:09:58 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Qm9UT-00070z-Ah for submit <at> debbugs.gnu.org; Wed, 27 Jul 2011 15:09:58 -0400 Received: from mail-vw0-f44.google.com ([209.85.212.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <nightstrike@HIDDEN>) id 1Qm6eE-0002ga-U7 for 9088 <at> debbugs.gnu.org; Wed, 27 Jul 2011 12:07:51 -0400 Received: by vws12 with SMTP id 12so1238072vws.3 for <9088 <at> debbugs.gnu.org>; Wed, 27 Jul 2011 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eFlSj83dBmbB6Z4m/jtIWbUx2ekIupQAJAyOAlVFydk=; b=xVGAddz4R9E5Qf2DZIbZGqA2nQ5D+FojQzKUhcPG7TjtsCMV5ypvUjN1MhStRMcQsq KGsgTllgYIUzYvtWvlcI3wOYtup1D1m2jZ8DK0wSfntPaonFr77F1aDPqYiMuu/O4s2C eg93U1XbgM3s/s7w4oxjQCC6jp1Fi91Bj8quM= MIME-Version: 1.0 Received: by 10.52.179.36 with SMTP id dd4mr231146vdc.263.1311782427962; Wed, 27 Jul 2011 09:00:27 -0700 (PDT) Received: by 10.52.157.67 with HTTP; Wed, 27 Jul 2011 09:00:27 -0700 (PDT) In-Reply-To: <CAFKYj4d54EoAq-z2fpwCy+uCGREVkaQeRmo=Q++o04+5dzAEaQ@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <20110718062030.325920@HIDDEN> <CAFKYj4d54EoAq-z2fpwCy+uCGREVkaQeRmo=Q++o04+5dzAEaQ@HIDDEN> Date: Wed, 27 Jul 2011 12:00:27 -0400 Message-ID: <CAF1jjLvqU_+Mf=82hpj_uQQh_BmPEoGXcGXM=7BVOKeEgCCoSQ@HIDDEN> Subject: Re: bug#9088: Java support From: NightStrike <nightstrike@HIDDEN> To: tsuna <tsunanet@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 9088 X-Mailman-Approved-At: Wed, 27 Jul 2011 15:09:56 -0400 Cc: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.6 (---) On Wed, Jul 20, 2011 at 1:04 AM, tsuna <tsunanet@HIDDEN> wrote: > What would be nice would be to have the ability to recompile only the > .java that changed. =A0So when you edit 2/3 files, then we'd build just > that, but in one command. make can handle this pretty well. If all the source files are listed as prerequisites, $? will list all the ones newer than the target. So, automake could easily write a rule to run the compiler against only the .java files that have changed.
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 27 Jul 2011 16:18:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 27 12:18:17 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Qm6oK-0002w0-R1 for submit <at> debbugs.gnu.org; Wed, 27 Jul 2011 12:18:17 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <stefano.lattarini@HIDDEN>) id 1Qm6oI-0002vs-I4 for 9088 <at> debbugs.gnu.org; Wed, 27 Jul 2011 12:18:15 -0400 Received: by wwf25 with SMTP id 25so1531522wwf.15 for <9088 <at> debbugs.gnu.org>; Wed, 27 Jul 2011 09:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=h4f0CcJJHQ7TV8WkQ0iprkumYc5+t5XQGa9lpeED/Ng=; b=BRjO+1u7K5eQp45X0NK+4Ob6Xb2L1ht42EhZjUJQyTlAV6i59VP0FwVeD7fGk/x/h3 SLQ8QXssNnWswfBY2VZMOLlKm0DRoPxgNahxLCH4jodwJ0w4Jgb5D57tGXLkxlesPv11 1Kr733u5gpCjZnWOwrsdZK+8gXQu+mG4kAaFU= Received: by 10.216.235.157 with SMTP id u29mr1258weq.24.1311783493785; Wed, 27 Jul 2011 09:18:13 -0700 (PDT) Received: from bigio.localnet (host224-94-dynamic.244-95-r.retail.telecomitalia.it [95.244.94.224]) by mx.google.com with ESMTPS id m46sm27414weq.5.2011.07.27.09.18.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:18:12 -0700 (PDT) From: Stefano Lattarini <stefano.lattarini@HIDDEN> To: automake@HIDDEN Subject: Re: bug#9088: Java support Date: Wed, 27 Jul 2011 18:18:01 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <CAFKYj4d54EoAq-z2fpwCy+uCGREVkaQeRmo=Q++o04+5dzAEaQ@HIDDEN> <CAF1jjLvqU_+Mf=82hpj_uQQh_BmPEoGXcGXM=7BVOKeEgCCoSQ@HIDDEN> In-Reply-To: <CAF1jjLvqU_+Mf=82hpj_uQQh_BmPEoGXcGXM=7BVOKeEgCCoSQ@HIDDEN> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107271818.02339.stefano.lattarini@HIDDEN> X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: 9088 Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org, NightStrike <nightstrike@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -4.0 (----) On Wednesday 27 July 2011, NightStrike wrote: > On Wed, Jul 20, 2011 at 1:04 AM, tsuna <tsunanet@HIDDEN> wrote: > > What would be nice would be to have the ability to recompile only the > > .java that changed. So when you edit 2/3 files, then we'd build just > > that, but in one command. > > make can handle this pretty well. If all the source files are listed > as prerequisites, $? will list all the ones newer than the target. > So, automake could easily write a rule to run the compiler against > only the .java files that have changed. > Good idea. In fact, this is how recompilation is currently handled by the JAVA primary (with few small complications to support VPATH builds). And in the 'java-work' branch, there is also a test `java-rebuild.test' checking these semantics. Thanks, Stefano
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Stefano Lattarini <stefano.lattarini@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Stefano Lattarini <stefano.lattarini@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 9088) by debbugs.gnu.org; 20 Jul 2011 05:05:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 20 01:05:14 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QjOy6-0007qk-Hk for submit <at> debbugs.gnu.org; Wed, 20 Jul 2011 01:05:14 -0400 Received: from mail-vx0-f172.google.com ([209.85.220.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <tsunanet@HIDDEN>) id 1QjOy0-0007qD-UD for 9088 <at> debbugs.gnu.org; Wed, 20 Jul 2011 01:05:09 -0400 Received: by vxi40 with SMTP id 40so3515851vxi.3 for <9088 <at> debbugs.gnu.org>; Tue, 19 Jul 2011 22:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mVRgU3EpNhbom5UUn6F4qAPIg95RmvVWIvtUyRNQg9g=; b=xPKmBDh/VyvILG5c9nLF0EAgOUeERbwnHdTOBJ/rEi9uf1AdNQ9xs9PmwqNFNiWE8K I56q1AfXBiEcI9YQdPzpfuKAF5EDRle+HmcitJRdZB2ZSlMQleeatIdeBqVLziG6NdOd Nw6i7s3DmyllIzfs3AqYN3d0mZeLhhy8UOOOg= Received: by 10.52.94.180 with SMTP id dd20mr7965387vdb.415.1311138299109; Tue, 19 Jul 2011 22:04:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.181.73 with HTTP; Tue, 19 Jul 2011 22:04:38 -0700 (PDT) In-Reply-To: <20110718062030.325920@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <20110718062030.325920@HIDDEN> From: tsuna <tsunanet@HIDDEN> Date: Tue, 19 Jul 2011 22:04:38 -0700 Message-ID: <CAFKYj4d54EoAq-z2fpwCy+uCGREVkaQeRmo=Q++o04+5dzAEaQ@HIDDEN> Subject: Re: bug#9088: Java support To: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 9088 Cc: Stefano Lattarini <stefano.lattarini@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -4.1 (----) On Sun, Jul 17, 2011 at 11:20 PM, Ralf Wildenhues <Ralf.Wildenhues@HIDDEN> wrote: > * Stefano Lattarini wrote on Fri, Jul 15, 2011 at 10:58:01AM CEST: >> I'd rather deprecate the JAVA primary, and then introduce a new `JARS' >> primary, to be used e.g. as follows: > > First off, we've _never_ removed support for a primary, and I don't > think we should. =A0Even just deprecating one is a sign for fairly big > time failure in the past, right? Well... to put it bluntly, what the _JAVA primary does is pretty much useless. So you can keep it as is, but it's going to confuse users even more than they already are. I don't think you can completely change the way the _JAVA primary behaves, as that would be even worse than deprecating it, from a backwards compatibility standpoint. Some people use the _JAVA primary (surprisingly): http://www.google.com/codesearch#search/&q=3Dfile:Makefile.am%20_JAVA%5Cs*:= ?=3D&type=3Dcs > (All the more reason to do good research before the second attempt.) Agreed. >> =A0 foo_jar_SOURCES =3D all.java foo.java >> =A0 bar_jar_SOURCES =3D all.java bar.java >> =A0 bar_jar_JAVACFLAGS =3D -nowarn >> =A0 bar_jar_JARFLAGS =3D -J-Xmx48M > >> This should cause the following behaviour: >> >> =A01. javac will be called (with the `-d' option), to generate .class fi= les >> =A0 =A0 from all.java and foo.java, and put them into a "private" direct= ory >> =A0 =A0 `.classes/foo_jar/'; > > Why a private directory? Well since you can't predict what files the compiler will generate, it's easier to collect the output of the compilation by telling it "dump everything under that directory". > How would that play well with subdir-objects? Not sure... How would you implement subdir-objects if you had a C compiler that compiled a whole project at once and if it produced .o files with names you couldn't really predict? > libtool? How does libtool come into the picture? I don't see how libtool is relevant to Java. >=A0What about per-target flags? =A0How would you write the rules > in absence of per-target flags? By "per-target flags" I take it that you mean "how do I compile this specific .o with this specific flag"? People don't do this in Java. I'm not aware of any Java project or anyone compiling each .java file one by one. It doesn't mean it doesn't exist, just that the overwhelming majority of Java people build a whole bunch of files at once, typically all the .java files that should end up in a .jar. > What about other compilers/environments? I didn't get that. >=A0What features do other java > build systems offer that users will want to see? =A0(Even if they're not > implemented right away, an implementation should take care not to > prevent them being added in the future through wrong decisions early on.) What would be nice would be to have the ability to recompile only the .java that changed. So when you edit 2/3 files, then we'd build just that, but in one command. One way of doing this I've been thinking about is to tell Automake that a .java becomes a .class simply by touching the .class, and each time we touch a .class we also echo the name of the .java to a file that serves as a "todo list". At linking time, we read the todo list, actually compile all these files at once, and then build the .jar with all the previous .class files and the newly built .class files. If this is feasible, it would be perfectly compatible with what was described so far. I'm not aware of any Java build system doing this (e.g. Ant or Maven), so that would be a competitive advantage for Automake. AFAIK most Java build systems don't even both doing dependency tracking (maybe with the exception of sbt). At least for Ant I'm pretty certain it doesn't, it just rebuilds everything all the time. >> > Alternate question: if Java was a brand new language Automake had >> > never heard of, how would I build my project with Automake without >> > doing what I'm doing now where I have custom rules for everything and >> > I need to hook myself into install- and dist-hooks to Do The Right >> > Thing? >> > >> Basically (and as far as my knowledge/understanding goes), you wouldn't; >> Automake is unfortunately quite unflexible in this regard. =A0Providing >> your own "all-local", "install-hook" and "uninstall-local" rules is >> probably the best route to follow. > > Well, you can have all other kinds of make rules (and Benoit has them), > pretty much as in a normal makefile. =A0Automake doesn't help you, but > also doesn't take much away from you here (except maybe the odd GNU make > construct it doesn't grok). I was just hoping there was a way to tell Automake "here's how you can turn a .java into a .class" and "here's how to put all the .class together to do a .jar" and have it generate all the rules for me, so I could leverage it to have "make dist", "make install" etc do the right thing. Because the way I did it (everything built manually) forces me to manually list all the files in EXTRA_DIST, manually install them or abuse some other primary (such as _DATA), etc. >> > Like isn't it possible to have a bin_PROGRAMS =3D foo.jar and >> > foo_jar_SOURCES =3D main.java and then tell automake how to transform = a >> > .java into a .class and then how to turn all the .class into a .jar? >> > It seems that when I try this, Automake dies with "Java source seen >> > but `GCJ' is undefined". >> > >> Yes, because Automake thinks you want to build foo.jar as a binary >> executable, and so it wants to use gcj to compile it. =A0This happens >> because you've listed foo.jar in a PROGRAMS primary, which is only >> meant for binary executables, not scripts or bytecode files (ok, I'm >> simplifying things a bit here, but the main point stands). > > Well, that could be fixed, no? =A0Question is what about @substed_program= s@. I didn't get this either. --=20 Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 18 Jul 2011 20:40:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 18 16:40:34 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QiucE-0004iZ-3I for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 16:40:34 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QiucB-0004iJ-9d for 9088 <at> debbugs.gnu.org; Mon, 18 Jul 2011 16:40:32 -0400 Received: (qmail 9797 invoked by uid 0); 18 Jul 2011 20:40:24 -0000 Received: from 77.58.247.232 by www014.gmx.net with HTTP; Mon, 18 Jul 2011 22:40:22 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 18 Jul 2011 22:40:22 +0200 From: "Ralf Wildenhues" <Ralf.Wildenhues@HIDDEN> In-Reply-To: <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> Message-ID: <20110718204022.254460@HIDDEN> MIME-Version: 1.0 References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> <20110718061734.325930@HIDDEN> <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> Subject: Re: bug#9088: Java support To: Jack Kelly <jack@HIDDEN> X-Authenticated: #13673931 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Mutt-Fcc: ~/Mail/outbox X-Mutt-References: <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+CPG8FDdiCFDE6UaweftgE4ucPd3Xsl10Zg3QzbG EEyniNcOWHSuY1bm1973W2wCq+5q9l4R7UpQ== Content-Transfer-Encoding: 8bit X-GMX-UID: AqgddlBWYW0teK/WsWZpJ3R8amthc9sq X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 9088 Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.8 (--) Hi Jack, * Jack Kelly wrote on Mon, Jul 18, 2011 at 09:33:58AM CEST: > On Mon, Jul 18, 2011 at 4:17 PM, Ralf Wildenhues wrote: > > * Jack Kelly wrote on Sat, Jul 16, 2011 at 06:13:58AM CEST: > >> Perhaps there should be support for a foo_jar_JARADD, that by analogy > >> to _LDADD, that specifies additional files to be included in the jar? > > > > Why would it have to be a new primary, instead of just reusing _LDADD? > > Because, IMO, it's conceptually different. The output's being > assembled with `jar', not `ld'. This argument is attached at the wrong reply of mine, and the rationale is not conclusive: if the concept of a jar output file were different from a library output file, then that would be an argument in favor of using _JARS rather than _LIBRARIES, but not one for using _JARADD rather than _LDADD. Also, I'm with John, in that *conceptually*, creating a jar is virtually the same as creating a library. It's that currently, compiler tools don't do a good job of hiding this concept behind a consistent implementation, but instead expose the internal details of the language. Much like what prompted libtool (way back when) to treat C and C++ libraries differently (which it unfortunately still does and has to). _JARS has some merits when its arguments are @substed@, but with <foo>_LDADD, automake knows exactly that it is working on a library or a jar by virtue of looking at <foo>. Cheers, Ralf
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 18 Jul 2011 16:25:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 18 12:25:09 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Qiqcz-0007J0-06 for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 12:25:09 -0400 Received: from mail-pv0-f172.google.com ([74.125.83.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <john.calcote@HIDDEN>) id 1QipcF-0005r9-0B for 9088 <at> debbugs.gnu.org; Mon, 18 Jul 2011 11:20:18 -0400 Received: by pvh18 with SMTP id 18so3452910pvh.3 for <9088 <at> debbugs.gnu.org>; Mon, 18 Jul 2011 08:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=wwZ6rsNFmfBO9864pWuR8kh8EvGMQ4iLdUQfMmeKtSM=; b=Hvxt16f/4OahvNuwfD676+CjXIu0+aZ9mZNhZVWVQhN2KzgIIituLK5npsnbDZwYwv umOO3PfgGXGQIxlvn8NxFPWnLpU0+rooxnWqm1NS5AhUlkXT7ZebCsuLlxd8yA37oo39 IWEopgMv9NexDlO41nzXuMgIK6xEMhu1AsHXM= Received: by 10.68.12.101 with SMTP id x5mr8180718pbb.267.1311002408991; Mon, 18 Jul 2011 08:20:08 -0700 (PDT) Received: from fusionlt4865b ([216.51.42.66]) by mx.google.com with ESMTPS id e9sm2523419pbh.60.2011.07.18.08.20.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 08:20:06 -0700 (PDT) From: "John Calcote" <john.calcote@HIDDEN> To: "'Jack Kelly'" <jack@HIDDEN>, "'Ralf Wildenhues'" <Ralf.Wildenhues@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> <20110718061734.325930@HIDDEN> <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> In-Reply-To: <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> Subject: RE: bug#9088: Java support Date: Mon, 18 Jul 2011 09:20:03 -0600 Message-ID: <013801cc455e$2cf35a50$86da0ef0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJDySj28qYwCSRzV4LAdNEXul/P4QI0Wqj5AjWa4u8B36zqNwLR8sQ4An5RBdiTplnVAA== Content-Language: en-us X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 9088 X-Mailman-Approved-At: Mon, 18 Jul 2011 12:25:04 -0400 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.6 (---) Jack, -----Original Message----- From: automake-bounces+john.calcote=3Dgmail.com@HIDDEN [mailto:automake-bounces+john.calcote=3Dgmail.com@HIDDEN] On Behalf Of = Jack Kelly Sent: Monday, July 18, 2011 1:34 AM To: Ralf Wildenhues Cc: 9088 <at> debbugs.gnu.org; automake@HIDDEN Subject: Re: bug#9088: Java support On Mon, Jul 18, 2011 at 4:17 PM, Ralf Wildenhues = <Ralf.Wildenhues@HIDDEN> wrote: > * Jack Kelly wrote on Sat, Jul 16, 2011 at 06:13:58AM CEST: >> On Sat, Jul 16, 2011 at 9:55 AM, tsuna wrote: >> > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini wrote: >> >> As my java foo is pretty weak, I'm not sure how to handle jar=20 >> >> manifests, jar entry points, or other jar/javac subtleties and advanced features. >> >> Suggestions welcome. >> > >> > You can create the manifest manually fairly easily. =A0Here's an=20 >> > example in the project I'm in the process of autotoolizing: >> > https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6 >> > 972eee6fdd1033d851/Makefile#L207 >> >> Perhaps there should be support for a foo_jar_JARADD, that by analogy = >> to _LDADD, that specifies additional files to be included in the jar? > > Why would it have to be a new primary, instead of just reusing _LDADD? Because, IMO, it's conceptually different. The output's being assembled = with `jar', not `ld'. Actually...conceptually, a jar is identical to a library identical: A library is an archive of objects. A jar is an archive of objects. Jar's happen to be compressed as well, but that's irrelevant. Conceptually, they're the same. I would argue in favor of different names for political reasons. :) = There's still a fairly large rift between C/C++ and Java developers.=20 --john
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 18 Jul 2011 07:34:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 18 03:34:13 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QiiLB-00030k-Pd for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 03:34:13 -0400 Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <endgame.dos@HIDDEN>) id 1QiiL6-00030E-Nm for 9088 <at> debbugs.gnu.org; Mon, 18 Jul 2011 03:34:08 -0400 Received: by wyj26 with SMTP id 26so1925691wyj.3 for <9088 <at> debbugs.gnu.org>; Mon, 18 Jul 2011 00:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7DAsrwU4BSC5FspXj+tr3VQItp0mYjaRtU2ArTWaOPk=; b=nmy8a1C2PjestEG9vfRBbPOAYl3o5+o9ZJ4O3i9l0scLHiiWAUoqBtPngKAp7wBVgP cNV+gcTAUTnoYCSevfe8eInHe8c8heAEQnhYHdWYq9gs77gA6NMeJo8wXbxNaJcPExNX wGN4jNu5+4J3AX6+Ij1n9SLeScAtoJDYneIh4= MIME-Version: 1.0 Received: by 10.217.7.66 with SMTP id z44mr4885676wes.100.1310974438818; Mon, 18 Jul 2011 00:33:58 -0700 (PDT) Received: by 10.216.160.203 with HTTP; Mon, 18 Jul 2011 00:33:58 -0700 (PDT) In-Reply-To: <20110718061734.325930@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> <20110718061734.325930@HIDDEN> Date: Mon, 18 Jul 2011 17:33:58 +1000 X-Google-Sender-Auth: S-MBR4iZHxDqxgDRzGW0f88Jqts Message-ID: <CAEnY7O8s0eVt_xcTGA9J=sGaXMd4ueTNrrxu=Q0pPXpSuL4kJA@HIDDEN> Subject: Re: bug#9088: Java support From: Jack Kelly <jack@HIDDEN> To: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 9088 Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.6 (---) On Mon, Jul 18, 2011 at 4:17 PM, Ralf Wildenhues <Ralf.Wildenhues@HIDDEN> w= rote: > * Jack Kelly wrote on Sat, Jul 16, 2011 at 06:13:58AM CEST: >> On Sat, Jul 16, 2011 at 9:55 AM, tsuna wrote: >> > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini wrote: >> >> As my java foo is pretty weak, I'm not sure how to handle jar manifes= ts, >> >> jar entry points, or other jar/javac subtleties and advanced features= . >> >> Suggestions welcome. >> > >> > You can create the manifest manually fairly easily. =A0Here's an examp= le >> > in the project I'm in the process of autotoolizing: >> > https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972= eee6fdd1033d851/Makefile#L207 >> >> Perhaps there should be support for a foo_jar_JARADD, that by analogy >> to _LDADD, that specifies additional files to be included in the jar? > > Why would it have to be a new primary, instead of just reusing _LDADD? Because, IMO, it's conceptually different. The output's being assembled with `jar', not `ld'. -- Jack
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at submit) by debbugs.gnu.org; 18 Jul 2011 06:20:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 18 02:20:51 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QihCE-0001Om-7R for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:20:50 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihCD-0001Oa-7e for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:20:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihC6-0002Tc-3V for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:20:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:54516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihC5-0002TP-Gd for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:20:41 -0400 Received: from eggs.gnu.org ([140.186.70.92]:45289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihC2-0005nK-Vx for bug-automake@HIDDEN; Mon, 18 Jul 2011 02:20:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihC0-0002SC-QO for bug-automake@HIDDEN; Mon, 18 Jul 2011 02:20:38 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:44613) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1QihBz-0002RW-OZ for bug-automake@HIDDEN; Mon, 18 Jul 2011 02:20:36 -0400 Received: (qmail 9155 invoked by uid 0); 18 Jul 2011 06:20:33 -0000 Received: from 77.58.247.232 by www029.gmx.net with HTTP; Mon, 18 Jul 2011 08:20:30 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 18 Jul 2011 08:20:30 +0200 From: "Ralf Wildenhues" <Ralf.Wildenhues@HIDDEN> In-Reply-To: <201107151058.02105.stefano.lattarini@HIDDEN> Message-ID: <20110718062030.325920@HIDDEN> MIME-Version: 1.0 References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> Subject: Re: Java support To: Stefano Lattarini <stefano.lattarini@HIDDEN> X-Authenticated: #13673931 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Mutt-Fcc: ~/Mail/outbox X-Mutt-References: <201107151058.02105.stefano.lattarini@HIDDEN> X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+MxJg25XqMGAxj8/AiDGDhZXSeRLMf22TmEVo1oS sE4vRw3dnkdI1LgmsiNEofq1bbGIEVtvdXgw== Content-Transfer-Encoding: 8bit X-GMX-UID: /aRGPjgeZCEERaXftWwhagF4IGhpZYYT X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit Cc: bug-automake@HIDDEN, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -4.3 (----) Hello, allow me a couple of ranty comments: * Stefano Lattarini wrote on Fri, Jul 15, 2011 at 10:58:01AM CEST: > I'd rather deprecate the JAVA primary, and then introduce a new `JARS' > primary, to be used e.g. as follows: First off, we've _never_ removed support for a primary, and I don't think we should. Even just deprecating one is a sign for fairly big time failure in the past, right? (All the more reason to do good research before the second attempt.) > jar_JARS = foo.jar > zardoz_JARS = bar.jar Why can they not be _LIBRARIES? (Honest question) > foo_jar_SOURCES = all.java foo.java > bar_jar_SOURCES = all.java bar.java > bar_jar_JAVACFLAGS = -nowarn > bar_jar_JARFLAGS = -J-Xmx48M > This should cause the following behaviour: > > 1. javac will be called (with the `-d' option), to generate .class files > from all.java and foo.java, and put them into a "private" directory > `.classes/foo_jar/'; Why a private directory? How would that play well with subdir-objects? libtool? What about per-target flags? How would you write the rules in absence of per-target flags? What about other compilers/environments? What features do other java build systems offer that users will want to see? (Even if they're not implemented right away, an implementation should take care not to prevent them being added in the future through wrong decisions early on.) > 2. similarly, javac will be called (this time also with the `-nowarn' > option) to generate .class files from all.java and bar.java, placing > them into the directory `.classes/bar_jar/'; > > 3. jar will be called to build `foo.jar' from all the .class files found > in .classes/foo_jar/; > > 4. similarly, jar will be called (this time with the `-J-Xmx48M' option) > to build `bar.jar' from all the .class files in .classes/foo_jar/; > > 5. "make mostlyclean" will remove the `.classes' directory; > > 6. "make clean" will also remove foo.jar and bar.jar; > > 7. "make install" will install foo.jar in $(jardir) (which we could make > default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we > expect to be user-defined). > > As my java foo is pretty weak, I'm not sure how to handle jar manifests, (I think you meant 'fu' here ;-) > jar entry points, or other jar/javac subtleties and advanced features. > Suggestions welcome. > > > My question now boils down to this: > > Has anyone already got some thoughts on how to make Automake play well > > with Java projects or what kind of workarounds can I use to leverage > > as much of Automake as possible while still building my Java stuff the > > way I want it? > > > > Alternate question: if Java was a brand new language Automake had > > never heard of, how would I build my project with Automake without > > doing what I'm doing now where I have custom rules for everything and > > I need to hook myself into install- and dist-hooks to Do The Right > > Thing? > > > Basically (and as far as my knowledge/understanding goes), you wouldn't; > Automake is unfortunately quite unflexible in this regard. Providing > your own "all-local", "install-hook" and "uninstall-local" rules is > probably the best route to follow. Well, you can have all other kinds of make rules (and Benoit has them), pretty much as in a normal makefile. Automake doesn't help you, but also doesn't take much away from you here (except maybe the odd GNU make construct it doesn't grok). > > Like isn't it possible to have a bin_PROGRAMS = foo.jar and > > foo_jar_SOURCES = main.java and then tell automake how to transform a > > .java into a .class and then how to turn all the .class into a .jar? > > It seems that when I try this, Automake dies with "Java source seen > > but `GCJ' is undefined". > > > Yes, because Automake thinks you want to build foo.jar as a binary > executable, and so it wants to use gcj to compile it. This happens > because you've listed foo.jar in a PROGRAMS primary, which is only > meant for binary executables, not scripts or bytecode files (ok, I'm > simplifying things a bit here, but the main point stands). Well, that could be fixed, no? Question is what about @substed_programs@. Cheers, Ralf
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 18 Jul 2011 06:17:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 18 02:17:51 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Qih9H-0001Kf-Ak for submit <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:17:51 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from <Ralf.Wildenhues@HIDDEN>) id 1Qih9C-0001KM-EG for 9088 <at> debbugs.gnu.org; Mon, 18 Jul 2011 02:17:46 -0400 Received: (qmail 6344 invoked by uid 0); 18 Jul 2011 06:17:36 -0000 Received: from 77.58.247.232 by www029.gmx.net with HTTP; Mon, 18 Jul 2011 08:17:34 +0200 (CEST) Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Date: Mon, 18 Jul 2011 08:17:34 +0200 From: "Ralf Wildenhues" <Ralf.Wildenhues@HIDDEN> In-Reply-To: <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> Message-ID: <20110718061734.325930@HIDDEN> MIME-Version: 1.0 References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> Subject: Re: bug#9088: Java support To: Jack Kelly <jack@HIDDEN> X-Authenticated: #13673931 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Mutt-Fcc: ~/Mail/outbox X-Mutt-References: <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18anjkxdb4awhuQpAtO/gPaGwNoR1DL/JRZaB3Kvb +hf/s4T4nobxTtwOqdOTK0a2to1DauzI1AdQ== X-GMX-UID: yfcWeho1RkkNc7/fo2Rq+z5udWkvKNNm X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 9088 Cc: tsuna <tsunanet@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) * Jack Kelly wrote on Sat, Jul 16, 2011 at 06:13:58AM CEST: > On Sat, Jul 16, 2011 at 9:55 AM, tsuna wrote: > > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini wrote: > >> As my java foo is pretty weak, I'm not sure how to handle jar manifests, > >> jar entry points, or other jar/javac subtleties and advanced features. > >> Suggestions welcome. > > > > You can create the manifest manually fairly easily. Here's an example > > in the project I'm in the process of autotoolizing: > > https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207 > > Perhaps there should be support for a foo_jar_JARADD, that by analogy > to _LDADD, that specifies additional files to be included in the jar? Why would it have to be a new primary, instead of just reusing _LDADD? Thanks, Ralf
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 16 Jul 2011 12:54:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 16 08:54:10 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Qi4Nm-0008A4-8N for submit <at> debbugs.gnu.org; Sat, 16 Jul 2011 08:54:10 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <stefano.lattarini@HIDDEN>) id 1Qi4Ni-00089Z-VN for 9088 <at> debbugs.gnu.org; Sat, 16 Jul 2011 08:54:08 -0400 Received: by wwf25 with SMTP id 25so1936573wwf.15 for <9088 <at> debbugs.gnu.org>; Sat, 16 Jul 2011 05:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=XG4ZO1w+UkSYf7Y8rp8Ac6pyaI24HxXQa+zSMgpjxYU=; b=DVjLIJMIZwddl7rCiGJNVbjnAVmaLGTIRu33RgTNXgcaVRk2FWEdjRN43n+k8DX3N4 VsWQaUqNWW8XysoCvCmnG/r398b/qkdNiVw8Yg6WoX9AE3EISrU7GUHGjcII652wu7aa zCcpEwUjvZhc+Fe1bWOrXDf+nSk6dBI+Y9VC0= Received: by 10.227.127.135 with SMTP id g7mr4023173wbs.96.1310820840037; Sat, 16 Jul 2011 05:54:00 -0700 (PDT) Received: from bigio.localnet (host87-49-dynamic.58-82-r.retail.telecomitalia.it [82.58.49.87]) by mx.google.com with ESMTPS id gd1sm1843885wbb.27.2011.07.16.05.53.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 05:53:58 -0700 (PDT) From: Stefano Lattarini <stefano.lattarini@HIDDEN> To: tsuna <tsunanet@HIDDEN> Subject: Re: bug#9088: Java support Date: Sat, 16 Jul 2011 14:53:48 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> In-Reply-To: <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107161453.49068.stefano.lattarini@HIDDEN> X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: 9088 Cc: 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.9 (---) On Saturday 16 July 2011, tsuna wrote: > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini > <stefano.lattarini@HIDDEN> wrote: > > You're right; the documentation on Java support should be definitely > > be improved (especially making better distinction between usual bytecode > > compilation with javac and "native/binary compilation" with gcj). > > I just sent a trivial patch to automake-patches (Message-Id: > <1310773785-4708-1-git-send-email-tsunanet@HIDDEN>) to add > cross-references between the two sections. I was rather confused when > I realized there were 2 different sections about Java in the manual. > I agree that the present situation is overly confusing; your patch offers a small but definite improvement, so I'll apply it. Thanks. > Eventually these 2 sections should be merged, > Note sure about that, as they deal with different situations. But maybe they can become distinct subsections of a new single "Java support" section (these subsections being named something on the line of "Support for bytecode-compiled Java" and "Compiling Java to native binaries with GCJ" -- suggestions for better titles are welcome). > but for now the cross-references will help remove some of the confusion. > Agreed. > > I'd rather deprecate the JAVA primary, and then introduce a new `JARS' > > primary, to be used e.g. as follows: > > > > jar_JARS = foo.jar > > zardoz_JARS = bar.jar > > foo_jar_SOURCES = all.java foo.java > > bar_jar_SOURCES = all.java bar.java > > bar_jar_JAVACFLAGS = -nowarn > > bar_jar_JARFLAGS = -J-Xmx48M > > > > This should cause the following behaviour: > > > > 1. javac will be called (with the `-d' option), to generate .class files > > from all.java and foo.java, and put them into a "private" directory > > `.classes/foo_jar/'; > > > > 2. similarly, javac will be called (this time also with the `-nowarn' > > option) to generate .class files from all.java and bar.java, placing > > them into the directory `.classes/bar_jar/'; > > > > 3. jar will be called to build `foo.jar' from all the .class files found > > in .classes/foo_jar/; > > > > 4. similarly, jar will be called (this time with the `-J-Xmx48M' option) > > to build `bar.jar' from all the .class files in .classes/foo_jar/; > > > > 5. "make mostlyclean" will remove the `.classes' directory; > > > > 6. "make clean" will also remove foo.jar and bar.jar; > > > > 7. "make install" will install foo.jar in $(jardir) (which we could make > > default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we > > expect to be user-defined). > > This sounds excellent. > Good. Notice however that I'm probably not going to tackle this issue anytime soon, as I'm in the middle of my GSoC project right now (but also notice that the present discussion is being duly registered in the bug tracker, so we're not losing our time here). > > As my java foo is pretty weak, I'm not sure how to handle jar manifests, > > jar entry points, or other jar/javac subtleties and advanced features. > > Suggestions welcome. > > You can create the manifest manually fairly easily. Here's an example > in the project I'm in the process of autotoolizing: > https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207 > Thanks, I'll take a look at that (when the times comes to write the patch). > It doesn't define an entry point, but you get the idea. The thing is, > manifests can (and frequently do) contain arbitrary fields, some of > which are standard (or de facto standards), some of which are not. So > I'm thinking the best thing would be to let people create their own > manifest if they wish to, and give them an easy way to specify what > file should be used as the manifest. If they don't specify anything, > then Automake would add rules to generate a fairly arbitrary manifest. > Regards, Stefano
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 16 Jul 2011 04:52:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 16 00:52:21 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QhwrT-00051y-NV for submit <at> debbugs.gnu.org; Sat, 16 Jul 2011 00:52:20 -0400 Received: from mail-yi0-f44.google.com ([209.85.218.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <tsunanet@HIDDEN>) id 1QhwrQ-00051m-JA for 9088 <at> debbugs.gnu.org; Sat, 16 Jul 2011 00:52:17 -0400 Received: by yie30 with SMTP id 30so845363yie.3 for <9088 <at> debbugs.gnu.org>; Fri, 15 Jul 2011 21:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RmTCwMV4fANA3PacsRZbVf5pSeeWpEp2WklfrvgNGNI=; b=oVmafwTuGe+MGmaj4Ud7DD0PZL8qUqDqnkcgDzJwMuJ5skBjl9Q8pnuIbgGdtIfigz uOnzzNO9QP0hB12FISmIvFR1DbZiF1qdBD6knOwwMitZ67dKowwFcZAUKcrFHPMv4USb QDpHrQWlOme4s5nvNkmYm3yqxhya6eDpDK23k= Received: by 10.236.179.106 with SMTP id g70mr5615769yhm.372.1310791931094; Fri, 15 Jul 2011 21:52:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.131.32 with HTTP; Fri, 15 Jul 2011 21:51:51 -0700 (PDT) In-Reply-To: <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> From: tsuna <tsunanet@HIDDEN> Date: Fri, 15 Jul 2011 21:51:51 -0700 Message-ID: <CAFKYj4epObnj+=p4PzN8vJRCOSLcaqesPCprWxjddFrcrZQMnA@HIDDEN> Subject: Re: bug#9088: Java support To: Jack Kelly <jack@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.8 (----) X-Debbugs-Envelope-To: 9088 Cc: Stefano Lattarini <stefano.lattarini@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -4.4 (----) On Fri, Jul 15, 2011 at 9:13 PM, Jack Kelly <jack@HIDDEN> wrote: > On Sat, Jul 16, 2011 at 9:55 AM, tsuna <tsunanet@HIDDEN> wrote: >> On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini >> <stefano.lattarini@HIDDEN> wrote: >>> As my java foo is pretty weak, I'm not sure how to handle jar manifests= , >>> jar entry points, or other jar/javac subtleties and advanced features. >>> Suggestions welcome. >> >> You can create the manifest manually fairly easily. =A0Here's an example >> in the project I'm in the process of autotoolizing: >> https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972ee= e6fdd1033d851/Makefile#L207 > > Perhaps there should be support for a foo_jar_JARADD, that by analogy > to _LDADD, that specifies additional files to be included in the jar? > Then the manifest is just another file. My Java-foo is also weak, so > I'm not 100% sure if that would actually work. You need to know specifically which file is to be used as the manifest file, because you need to pass it to "jar". The dependent jar files need to be separated because you need to use them to assemble a classpath (e.g. "-cp dep1.jar:dep2.jar:some/directory"). --=20 Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at 9088) by debbugs.gnu.org; 16 Jul 2011 04:14:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 16 00:14:07 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QhwGV-0004Am-1L for submit <at> debbugs.gnu.org; Sat, 16 Jul 2011 00:14:07 -0400 Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <endgame.dos@HIDDEN>) id 1QhwGS-0004AD-VC for 9088 <at> debbugs.gnu.org; Sat, 16 Jul 2011 00:14:05 -0400 Received: by wyj26 with SMTP id 26so1193972wyj.3 for <9088 <at> debbugs.gnu.org>; Fri, 15 Jul 2011 21:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=72bbnG4db95NlP5swNPCwbP03t/Wo7B6hERcp0mnvgU=; b=oW8KRx/fso9R3SMSnZvboJ2xuuMu+Ga/b5ZNRBcRbhQKO/WdyIhmfe6g5uSu3OHaom MMM41cD4tBJ/SnSjeY6L03+fAGIF+3p9DKpd51YBFDYaSO3FKRFKkU16Fx5N1qnjOgzQ IULAtlo87td224OvELNkjVjvUM+IBR6oM6Sko= MIME-Version: 1.0 Received: by 10.216.137.91 with SMTP id x69mr3454851wei.93.1310789638915; Fri, 15 Jul 2011 21:13:58 -0700 (PDT) Received: by 10.216.208.158 with HTTP; Fri, 15 Jul 2011 21:13:58 -0700 (PDT) In-Reply-To: <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> Date: Sat, 16 Jul 2011 14:13:58 +1000 X-Google-Sender-Auth: J_7TbKbUFRHSAKy8ImT5oJqlbnI Message-ID: <CAEnY7O806PhkvD6YO02J35tYKm-53UsAVejxrBJUpsVBonYaAA@HIDDEN> Subject: Re: bug#9088: Java support From: Jack Kelly <jack@HIDDEN> To: tsuna <tsunanet@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 9088 Cc: Stefano Lattarini <stefano.lattarini@HIDDEN>, 9088 <at> debbugs.gnu.org, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.6 (---) On Sat, Jul 16, 2011 at 9:55 AM, tsuna <tsunanet@HIDDEN> wrote: > On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini > <stefano.lattarini@HIDDEN> wrote: >> As my java foo is pretty weak, I'm not sure how to handle jar manifests, >> jar entry points, or other jar/javac subtleties and advanced features. >> Suggestions welcome. > > You can create the manifest manually fairly easily. =A0Here's an example > in the project I'm in the process of autotoolizing: > https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee= 6fdd1033d851/Makefile#L207 Perhaps there should be support for a foo_jar_JARADD, that by analogy to _LDADD, that specifies additional files to be included in the jar? Then the manifest is just another file. My Java-foo is also weak, so I'm not 100% sure if that would actually work. -- Jack
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Jul 2011 23:59:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 15 19:59:42 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QhsIH-0006xL-JU for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 19:59:42 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <tsunanet@HIDDEN>) id 1QhsEk-0006s7-Js for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 19:56:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <tsunanet@HIDDEN>) id 1QhsEe-00019k-HQ for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 19:55:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:36505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <tsunanet@HIDDEN>) id 1QhsEe-00019c-Fb for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 19:55:56 -0400 Received: from eggs.gnu.org ([140.186.70.92]:40416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <tsunanet@HIDDEN>) id 1QhsEd-0000Da-6A for bug-automake@HIDDEN; Fri, 15 Jul 2011 19:55:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <tsunanet@HIDDEN>) id 1QhsEc-00019C-0i for bug-automake@HIDDEN; Fri, 15 Jul 2011 19:55:55 -0400 Received: from mail-yi0-f41.google.com ([209.85.218.41]:38289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <tsunanet@HIDDEN>) id 1QhsEb-000194-UY; Fri, 15 Jul 2011 19:55:53 -0400 Received: by yia13 with SMTP id 13so849382yia.0 for <multiple recipients>; Fri, 15 Jul 2011 16:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=m3iIBGC4LB8ErQaJlYpFzFHXQOYgzHkPxIehN42j8Uo=; b=fR3uRJ9iBF9rWm+K7JOy+HDzFxdWEIVHI6ipaLg1OR8ISJsD/sp718TH+zEMn4ljae wjvWfi0C8YBi48TStsrkPvEcOTzD3JHG4L04zFJ6v3MlMS1Q27TwNs+p4zKDBF/hKN0l ERtwldEtSHkuZmjPB3VW9BOHfQhYqVrkxnfMM= Received: by 10.150.193.2 with SMTP id q2mr4216672ybf.81.1310774153148; Fri, 15 Jul 2011 16:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.131.32 with HTTP; Fri, 15 Jul 2011 16:55:33 -0700 (PDT) In-Reply-To: <201107151058.02105.stefano.lattarini@HIDDEN> References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN> <201107151058.02105.stefano.lattarini@HIDDEN> From: tsuna <tsunanet@HIDDEN> Date: Fri, 15 Jul 2011 16:55:33 -0700 Message-ID: <CAFKYj4f0tsrnF+BuJF7kA3umw2KnhGxetcFJ7NfpVM=shwN07Q@HIDDEN> Subject: Re: Java support To: Stefano Lattarini <stefano.lattarini@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 15 Jul 2011 19:59:40 -0400 Cc: bug-automake@HIDDEN, automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -5.9 (-----) On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini <stefano.lattarini@HIDDEN> wrote: > You're right; the documentation on Java support should be definitely > be improved (especially making better distinction between usual bytecode > compilation with javac and "native/binary compilation" with gcj). I just sent a trivial patch to automake-patches (Message-Id: <1310773785-4708-1-git-send-email-tsunanet@HIDDEN>) to add cross-references between the two sections. I was rather confused when I realized there were 2 different sections about Java in the manual. Eventually these 2 sections should be merged, but for now the cross-references will help remove some of the confusion. > I'd rather deprecate the JAVA primary, and then introduce a new `JARS' > primary, to be used e.g. as follows: > > =A0jar_JARS =3D foo.jar > =A0zardoz_JARS =3D bar.jar > =A0foo_jar_SOURCES =3D all.java foo.java > =A0bar_jar_SOURCES =3D all.java bar.java > =A0bar_jar_JAVACFLAGS =3D -nowarn > =A0bar_jar_JARFLAGS =3D -J-Xmx48M > > This should cause the following behaviour: > > =A01. javac will be called (with the `-d' option), to generate .class fil= es > =A0 =A0from all.java and foo.java, and put them into a "private" director= y > =A0 =A0`.classes/foo_jar/'; > > =A02. similarly, javac will be called (this time also with the `-nowarn' > =A0 =A0option) to generate .class files from all.java and bar.java, placi= ng > =A0 =A0them into the directory `.classes/bar_jar/'; > > =A03. jar will be called to build `foo.jar' from all the .class files fou= nd > =A0 =A0in .classes/foo_jar/; > > =A04. similarly, jar will be called (this time with the `-J-Xmx48M' optio= n) > =A0 =A0to build `bar.jar' from all the .class files in .classes/foo_jar/; > > =A05. "make mostlyclean" will remove the `.classes' directory; > > =A06. "make clean" will also remove foo.jar and bar.jar; > > =A07. "make install" will install foo.jar in $(jardir) (which we could ma= ke > =A0 =A0default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we > =A0 =A0expect to be user-defined). This sounds excellent. > As my java foo is pretty weak, I'm not sure how to handle jar manifests, > jar entry points, or other jar/javac subtleties and advanced features. > Suggestions welcome. You can create the manifest manually fairly easily. Here's an example in the project I'm in the process of autotoolizing: https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6f= dd1033d851/Makefile#L207 It doesn't define an entry point, but you get the idea. The thing is, manifests can (and frequently do) contain arbitrary fields, some of which are standard (or de facto standards), some of which are not. So I'm thinking the best thing would be to let people create their own manifest if they wish to, and give them an easy way to specify what file should be used as the manifest. If they don't specify anything, then Automake would add rules to generate a fairly arbitrary manifest. --=20 Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
Received: (at submit) by debbugs.gnu.org; 15 Jul 2011 08:59:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 15 04:59:01 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1QheEc-0001jD-2H
for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 04:59:01 -0400
Received: from eggs.gnu.org ([140.186.70.92])
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <stefano.lattarini@HIDDEN>) id 1QheEW-0001iw-ED
for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 04:58:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1QheEM-0007NQ-SR
for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 04:58:47 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,
T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1
Received: from lists.gnu.org ([140.186.70.17]:39685)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1QheEM-0007NM-I8
for submit <at> debbugs.gnu.org; Fri, 15 Jul 2011 04:58:42 -0400
Received: from eggs.gnu.org ([140.186.70.92]:54906)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1QheEH-0007bV-OI
for bug-automake@HIDDEN; Fri, 15 Jul 2011 04:58:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1QheED-0007MO-6E
for bug-automake@HIDDEN; Fri, 15 Jul 2011 04:58:37 -0400
Received: from mail-ww0-f49.google.com ([74.125.82.49]:64535)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>)
id 1QheE2-0007L2-L1; Fri, 15 Jul 2011 04:58:22 -0400
Received: by wwf22 with SMTP id 22so864921wwf.30
for <multiple recipients>; Fri, 15 Jul 2011 01:58:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=from:to:subject:date:user-agent:cc:references:in-reply-to
:mime-version:content-type:content-transfer-encoding:message-id;
bh=MVdEw66msMkSSvnDMsFTJxR23amsfKIVvc8+7sPu7Q0=;
b=PXPL2ayHHfh1oAeTIAkY0M5fGeWBQ+1la7neL51K18WO6ieOuaK7G7BQDw/ezjm4bE
QxLxeV0Bt4DSK6etqPwiZzzdmhNksQbAbCfWtVe1baUK1PPGvBDfdaX8OF/78nbXmnTx
Xkv5ebuPx3ztjFNiUxPoOrDk89HEGp8i9eF4s=
Received: by 10.216.85.2 with SMTP id t2mr2754504wee.88.1310720299663;
Fri, 15 Jul 2011 01:58:19 -0700 (PDT)
Received: from bigio.localnet
(host93-95-dynamic.0-87-r.retail.telecomitalia.it [87.0.95.93])
by mx.google.com with ESMTPS id m46sm145346weq.5.2011.07.15.01.58.15
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 15 Jul 2011 01:58:17 -0700 (PDT)
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
To: automake@HIDDEN
Subject: Java support
Date: Fri, 15 Jul 2011 10:58:01 +0200
User-Agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )
References: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN>
In-Reply-To: <CAFKYj4e9oJksn7vftsuBZeHmFxNfp5vSSXdU40SXngU2nwUpJg@HIDDEN>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201107151058.02105.stefano.lattarini@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-Received-From: 140.186.70.17
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
Cc: tsuna <tsunanet@HIDDEN>, bug-automake@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -5.0 (-----)
[Adding bug-automake in CC:, so that we won't forget about the issue]
On Thursday 14 July 2011, tsuna wrote:
> Hi all,
> whether I like it or not, it so happens that I have a Java project I'm
> trying to package properly, and I'm trying to use autoconf/automake
> for maximum portability and ease of integration with various distros
> (since most of them have tools to automagically build packages on
> properly autotoolized projects), not to mention all the usual benefits
> that the autotools provide out of the box.
>
> I'm aware of http://sources.redhat.com/automake/automake.html#Java-Support
> (support via GCJ) but that's not what I want. Most of the Java people
> don't use GCJ, they use Sun's JDK. Somewhat confusingly perhaps, that
> section of the documentation doesn't refer to
> http://sources.redhat.com/automake/automake.html#Java which seems to
> be closer to what I want.
>
You're right; the documentation on Java support should be definitely
be improved (especially making better distinction between usual bytecode
compilation with javac and "native/binary compilation" with gcj).
> It's not clear from that part of the
> documentation how to get a .jar and have it installed etc. I read the
> code in lib/am/java.am and it seems all it does is to compile all the
> .java files into .class files and install the .class files.
>
Sadly true. And IMHO adding support for generating and installing .jar
files would be definitely worthwhile. BTW, I had already given some
thoughts to this possibility, but I wasn't sure if there would be enough
user interest to warrant a change in this direction; your mail seems to
show that indeed there is some interest at least (thank you for that!).
> The good
> thing about this is that it's compiling all the .java files at once
> (and not one-by-one like we do with C/C++ files), the bad thing is
> that it has no facility to produce and install a .jar file that
> contains all the .class files,
> and it only supports one _JAVA target per Makefile.am.
>
Yes (but my proposal below about a new JARS primary should allow us
to easily remove this limitation).
> I noticed there's a branch called "java-work", however it's not clear
> to me what improvements it has, and its lib/am/java.am seems pretty
> much identical.
>
Yes, so far that branch has only dealt with small bug fixes and
improved testsuite coverage.
> One of the problems noted in the manual and in Automake's code is that
> a single .java files doesn't predictably translate into a .class file.
> And there's no equivalent to gcc -M in the Java world. "Foo.java" is
> pretty much guaranteed to produce "Foo.class", but frequently there
> will be other class files of the form "Foo$Something.class" produced
> (this is because the nested class "Something" in the class "Foo" is
> compiled into its own file). Right now in my project I build pretty
> much everything with custom rules (even though I just switched from
> plain Make to Automake) and the approach I've used to work around this
> problem is to assume that "Foo.java" will produce "Foo*.class". I
> don't know if Automake could use this approach too, since there are
> cases where this will glob unrelated files, but it's working like a
> charm in my project. Ideally we should look for "Foo.class" and,
> maybe, "Foo$*.class", however the `maybe' part is annoying because if
> the globbing pattern doesn't match anything, it'll stay as is or,
> worse, produce an error with some shells (e.g. zsh with certain
> options).
>
I'd rather deprecate the JAVA primary, and then introduce a new `JARS'
primary, to be used e.g. as follows:
jar_JARS = foo.jar
zardoz_JARS = bar.jar
foo_jar_SOURCES = all.java foo.java
bar_jar_SOURCES = all.java bar.java
bar_jar_JAVACFLAGS = -nowarn
bar_jar_JARFLAGS = -J-Xmx48M
This should cause the following behaviour:
1. javac will be called (with the `-d' option), to generate .class files
from all.java and foo.java, and put them into a "private" directory
`.classes/foo_jar/';
2. similarly, javac will be called (this time also with the `-nowarn'
option) to generate .class files from all.java and bar.java, placing
them into the directory `.classes/bar_jar/';
3. jar will be called to build `foo.jar' from all the .class files found
in .classes/foo_jar/;
4. similarly, jar will be called (this time with the `-J-Xmx48M' option)
to build `bar.jar' from all the .class files in .classes/foo_jar/;
5. "make mostlyclean" will remove the `.classes' directory;
6. "make clean" will also remove foo.jar and bar.jar;
7. "make install" will install foo.jar in $(jardir) (which we could make
default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we
expect to be user-defined).
As my java foo is pretty weak, I'm not sure how to handle jar manifests,
jar entry points, or other jar/javac subtleties and advanced features.
Suggestions welcome.
> My question now boils down to this:
> Has anyone already got some thoughts on how to make Automake play well
> with Java projects or what kind of workarounds can I use to leverage
> as much of Automake as possible while still building my Java stuff the
> way I want it?
>
> Alternate question: if Java was a brand new language Automake had
> never heard of, how would I build my project with Automake without
> doing what I'm doing now where I have custom rules for everything and
> I need to hook myself into install- and dist-hooks to Do The Right
> Thing?
>
Basically (and as far as my knowledge/understanding goes), you wouldn't;
Automake is unfortunately quite unflexible in this regard. Providing
your own "all-local", "install-hook" and "uninstall-local" rules is
probably the best route to follow.
> Like isn't it possible to have a bin_PROGRAMS = foo.jar and
> foo_jar_SOURCES = main.java and then tell automake how to transform a
> .java into a .class and then how to turn all the .class into a .jar?
> It seems that when I try this, Automake dies with "Java source seen
> but `GCJ' is undefined".
>
Yes, because Automake thinks you want to build foo.jar as a binary
executable, and so it wants to use gcj to compile it. This happens
because you've listed foo.jar in a PROGRAMS primary, which is only
meant for binary executables, not scripts or bytecode files (ok, I'm
simplifying things a bit here, but the main point stands).
> Thanks and sorry for the longish email.
>
Well, thanks to you for rekindling interest in the Automake Java
support :-)
Regards,
Stefano
Stefano Lattarini <stefano.lattarini@HIDDEN>:bug-automake@HIDDEN.
Full text available.owner <at> debbugs.gnu.org, bug-automake@HIDDEN:bug#9088; Package automake.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.