At 11:25 AM 3/19/01 -0600, you wrote:
>> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, March 19, 2001 11:21 AM
>> To: Schewe, Jon (MN65)
>> Cc: [EMAIL PROTECTED]
>> Subject: RE: PROPOSAL: New Java Build Feature
>>
>>
>> At 10:57 AM 3/19/01 -0600, you wrote:
>> >Have you thought about using jikes for dependancy checking?
>> Or even just
>> >taking the dependancy checking code out of it and using that
>> separatly? It
>> >is open source and I've found it's dependancy checking to be
>> most excellent.
>>
>> Yes, I have and rejected it for the following reasons:
>>
>> 1. It does not produce JPDA compatible classes and so the
>> classes that
>> it produces cannot be debugged with JDEbug or (new)jdb).
>
>I realize that and do not suggest using jikes for the actual compiling, just
>grab the dependancy engine.
>
>> 2. I have encountered other obscure compile problems with jikes that
>> have destroyed any confidence that I had in the classes
>> that it creates.
>
>I'm sorry to hear that, I've found it to adhear to the Java Language Spec
>better, but never seen problems.
>
If it adheres to the specs so well, why does it produce class files that
are incompatible with
JPDA?
>> 3. I tried using the dependency files that it produced in a
>> make file and
>> I could never get them to work correctly with make. Yes,
>> all the class
>> files that needed to be rebuilt would be
>> rebuilt--sometimes many times
>> because both jikes and make were doing dependency
>> checking on the same file set, totally unaware of each
>> other. Further,
>> the dependency files would not work for projects that
>> maintain source
>> and class files in separate directories, which is the
>> organization that
>> I favor.
>
>Yes, I've seen this as well, however the +F flag works well, I am suggesting
>we take the logic from this and encapsulate this in some library or
>something useful for JDE.
>
I don't understand your point. You admit that what I say is true and then
you reiterate that jikes dependency checking "works well." Hell, I could
simply recompile every single file in my project everytime I rebuild the
project and that would "work well" too.
Further, everytime these discussions come up, this issue is always avoided
by proponents of using jikes-generated dependency rules in a makefile,
namely that this causes TWO DIFFERENT PROGRAMS TO DO DEPENDENCY CHECKING
CONCURRENTLY AND NEITHER IS AWARE OF THE OTHER SO THAT FILES GET REBUILT
MORE TIMES THAN IS NECESSARY. This is not WORKING WELL to my mind. It
defeats the whole point of doing dependency checking. What I am proposing
is a scheme that uses only one program to do dependency checking during the
build process, namely javac (or jikes if you prefer). There is no need to
use make's dependency checking at all. You can even include this proposal
as part of the make file. Further, think of the compile master as the
dependency file for the make process. The only difference is that it is a
dependecy file used by the COMPILER's dependency checker not by MAKE's
dependency checker. Furthermore, you need to invoke the compiler ONLY ONCE.
[snip]
>
>I tried doing a compile master back with JDK 1.1.x and it didn't work for
>me. My test cases was to just do imports of all classes, I realize that
>import * won't work either and did try listing them explicitly with an empty
>body and didn't get much success.
I don't use imports. I put a dummy field in the CompileMaster for every
class in the package (see my other postings on this thread for an example
of a CompileMaster). That seems to work just fine. I've tried it and all
out-of-date classes get rebuilt, even classes that have indirect
dependencies on each other.
- Paul
