bug#9088: Java, JARS primary?

[Michael Zucchi]

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