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