langtools in b20
Rémi Forax
forax at univ-mlv.fr
Mon Sep 24 09:42:33 PDT 2007
Jonathan Gibbons a écrit :
>
> 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.
it is deleted, at least marked as deleted. I talk about the headers of
the files just before being deleted.
...
>> 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)
ok, this is corrected.
>>
>> 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?
yes
> 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?
no, this is not the standard case, i've patched the interface and all
implementations so it should recompile supertype and subtypes.
> I'll really like to see this fixed; it would be a great application
> for JSR199/269, to obtain and use accurate dependency info.
yes, it could be great, especially if it is integrated to ant.
>
>
>
> -- Jon
>
Rémi
More information about the compiler-dev
mailing list