Forgot the attachment.
# '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 '.'
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-sourc
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
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 AP
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 spe
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 metho
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 wr
