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
