langtools in b20

[Jonathan Gibbons]

On Sep 23, 2007, at 5:38 PM, Rémi Forax wrote:

>
> no,
> headers of files from https://openjdk.dev.java.net/svn/openjdk/ 
> compiler/trunk
> seems more accurate than headers of files from https:// 
> openjdk.dev.java.net/svn/openjdk/jdk/trunk/langtools


Thanks for the specific path names; I'' check this out, but it is  
more likely that the langtools ones are the most accurate; they come  
from the definitive internal (soon to be external) workspace.    
Actually, compiler/trunk should be deleted; I'll investigate having  
that done.


>>
>>>
>>>>
>>>> I assume you can edit the files in the javax.lang.model package OK;
>>> yes
>>
>>>> what problems are you having when you try and compile the  
>>>> workspace?
>>> javax.model.* is a part of JDK so when i compile a patched  
>>> version javac/tree/JCTree.java,
>>> that adds two new trees, the build process use the package  
>>> javax.model.element of the boot jdk and not
>>> the one that you can find in the source folder.
>>
>> The build process should be putting all the necessary files on the  
>> command line.  Can you provide some script output to show what you  
>> are doing and how it is going wrong for you.
> ok, it's compile now, i've made "ant clean" and it's working
> (almost because it seems i forget that    "byte data[]" is a valid  
> field declaration,
> but that is another story)
>
> So i think there is a dependency problem with in the build.xml,
> here is the use case:
> 1) compile the whole repository
>    "ant"
> 2) patch the source file (here com.sun.source.tree.TreeVisitor)
> 3) compile using ant
>    -> some files in /build/bootstrap/classes/ are not recompiled
>        so it fails
> 3bis) use "ant clean; ant"
>         it compiles


OK, thanks; I'll try and recreate that scenario.  I'm guessing you  
were adding methods to TreeVisitor, right?  Stupid question, are you  
just running into the "standard" problem that none of ant/make/javac  
does a proper job of dependency analysis?  If you edit and recompile  
an interface or abstract class, ant will not know to recompile any  
subtypes that might need recompiling? I'll really like to see this  
fixed; it would be a great application for JSR199/269, to obtain and  
use accurate dependency info.



-- Jon