Hi Calum, As I mentioned in my previous postings, make resolves dependencies using compiled classes. If you did not modify MyClass then the java file is considered up-to-date and MyClass is not recompiled. We also cannot find any ambiguities since the class file does not contain any information about imports. The problem could have been solved if the make used sources (java files instead compiled classes) for dependency resolution, but we haven't developed an efficient way to do this yet.
Best regards, Eugene Zhuravlev JetBrains, Inc / IntelliJ Software, http://www.intellij.com/ "Develop with pleasure!" ----- Original Message ----- From: "Calum Maclean" <[EMAIL PROTECTED]> To: "IntelliJ Mailing List (E-mail)" <[EMAIL PROTECTED]> Sent: Thursday, April 11, 2002 18:11 Subject: [Eap-list] Bug in dependency-based compiling > Say I've got a class as follows: > > package mypackage; > import java.util.*; > public class MyClass > { > private List list; > // ... remainder of class > } > > So MyClass uses List from java.util. > Suppose I then add a List class to mypackage. This makes the List reference > ambiguous (or it picks up the one in the local package - can't remember). > Anyway, MyClass is now invalid. However, if I do a Make Project, it doesn't > recompile MyClass. > > Calum > CONFIDENTIALITY NOTICE: This message is confidential and for the use only of > the intended recipient. If you receive the message in error you are not > entitled to disseminate, copy or use the contents in any way. In such > circumstances please forward the message back to the sender or contact IT > Services at the group's parent company - Aspects Software Ltd, by telephone > on +44 (0) 131 225 9500. WARNING: While Aspects Software Ltd and all > its subsidiaries take steps to prevent computer viruses from being > transmitted via electronic mail attachments we cannot guarantee that > attachments do not contain computer virus code. You are therefore strongly > advised to undertake anti virus checks prior to accessing the attachment to > this electronic mail. Neither Aspects Software Ltd nor any of its > subsidiaries grants any warranties regarding performance use or quality of > any attachment and undertakes no liability for loss or damage howsoever > caused. > > _______________________________________________ > Eap-list mailing list > [EMAIL PROTECTED] > http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
