[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Incremental Compilation problems.
|
> On that note, here's a question: I moved to a model of accepting any
command-line
> option in a config file and in the text area for additional
(non-standard) compiler
> options, mainly to share code with the command-line compiler option
processing and
> to work around limitations in ajbrowser interface. So there's a process
of
> determining the actual build configuration from a union of sorts on the
local build
> config file, the project properties, and the build options, each
potentially holding
> any option. However, I expected (and left room for) the various IDE
support to fixup
> the resulting options (e.g., to force the use of project classpath rather
than a local
> classpath). Will that work for AJDT?
I'm not sure how the other IDEs (including ajbrowser) operate with respect
to options
processing. AJDT holds sets of build controls/settings in implementations
of
org.aspectj.ajde.ProjectPropertiesAdapter and
org.aspectj.ajde.BuildOptionsAdapter - when a
project is compiled through Ajde.getDefault().getBuildManager().build(<lst
location>) AJDE asks
our implementations of those interfaces for the various settings. It
sounds like this fits in OK
with the scheme you outline in your note above. I'm interested in how you
control incremental
compilation without exposing it through projectproperties or buildoptions?
Do you use the
technique you mention about 'IDE support to fixup the resulting options' -
what do you mean by
that? I'm just wondering if I should be using the same scheme for AJDT you
see.
cheers,
Andy.
|---------+---------------------------->
| | Wes Isberg |
| | <wes@california.c|
| | om> |
| | |
| | 29/04/2003 18:27 |
|---------+---------------------------->
>-----------------------------------------------------------------------------------------------------------------------|
| |
| To: aspectj-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [aspectj-dev] Incremental Compilation problems. |
| |
| |
>-----------------------------------------------------------------------------------------------------------------------|
You might be seeing new bug 37020.
I suspect the code wrt obtaining the source file will need to be hardened
-- though I haven't seen that problem in my tree.
Also, working in parallel (as I mentioned to Adrian only, sorry), I have
incremental (and error handling and options processing and structure model
display) working for ajbrowser, except for some options saving and
processing problems.
I also did this, which I think is right:
> ProjectPropertiesAdapter and enhancing
> CompilerAdapter.configureProjectOptions
One gotcha: I refactored AjdtCommand's batch and incremental build methods
to share code,and when building incrementally, I do *not* reinitialize
BcelWorld as it used to, so I get the whole structure model (before I was
only getting the model for any touched components). (I also extended
CompilerAdapter with new API's for restarting a batch build when in
incremental mode, etc.)
On that note, here's a question: I moved to a model of accepting any
command-line option in a config file and in the text area for additional
(non-standard) compiler options, mainly to share code with the command-line
compiler option processing and to work around limitations in ajbrowser
interface. So there's a process of determining the actual build
configuration from a union of sorts on the local build config file, the
project properties, and the build options, each potentially holding any
option. However, I expected (and left room for) the various IDE support to
fixup the resulting options (e.g., to force the use of project classpath
rather than a local classpath). Will that work for AJDT?
In any case, I'll try to get to a fixed state ASAP. Because I'm working
mostly on Mik's code, I was holding off until I'd well-tested any changes.
You're welcome to send a patch. We can coordinate further directly.
Thanks -
Wes
P.S. - We re-process the config file options for each incremental
compilation and for successive batch compiles on the same file. At some
point AJDE should support a dirty bit for these configurations to avoid
reprocessing. That won't happen this release.
Andrew Clement wrote:
>
> Thanks to Wes for putting Miks initial changes into aspectj. I'm now
trying to get incremental working under AJDT - with mixed results. The
first job was exposing the option to set incremental compilation on/off -
which I did by extending (in aspectj) ProjectPropertiesAdapter and
enhancing CompilerAdapter.configureProjectOptions - if we think thats the
right way to do it, I'll post a patch.
>
> But, on to the important stuff. Now I've got a configuration option at
the project level for incremental. It seems to actually work in terms of
building a new system incrementally - but the outline view is a bit shaky.
Sometimes it goes blank (showing 'compile to view structure'), but the
worst thing I've been seeing is an NPE from this new bit of code in
AsmBuilder.java. The NPE is on the line 'child.getSourceLocation
().getSourceFile().equals(file)':
>
> // if the node already exists remove before adding
> ProgramElementNode duplicate = null;
> for (Iterator itt = StructureModelManager.INSTANCE.getStructureModel
().getRoot().getChildren().iterator(); itt.hasNext(); ) {
> ProgramElementNode child = (ProgramElementNode)itt.next();
> if (child.getSourceLocation().getSourceFile().equals(file)) {
> duplicate = child;
> }
> }
> if (duplicate != null) {
> StructureModelManager.INSTANCE.getStructureModel().getRoot
().removeChild(duplicate);
> }
> StructureModelManager.INSTANCE.getStructureModel().getRoot
().addChild(cuNode);
>
> I instrumented it (in an ugly fashion) like this:
>
> // if the node already exists remove before adding
> ProgramElementNode duplicate = null;
> StructureNode sn = StructureModelManager.INSTANCE.getStructureModel
().getRoot();
> String info = new String(sn.toString()+" kind = "+sn.getKind());
> for (Iterator itt = sn.getChildren().iterator(); itt.hasNext(); ) {
> ProgramElementNode child = (ProgramElementNode)itt.next();
> if (child==null) {
> System.err.println(">> root "+info+" child is null");
> } else {
> if (child.getSourceLocation()==null)
> System.err.println(">> root "+info+" child is "+child+" but
sourceloc is null");
> else if (child.getSourceLocation().getSourceFile()==null)
> System.err.println(">> root "+info+" child is "+child+" but
sourcefile is null");
>
> if (child.getSourceLocation().getSourceFile().equals(file)) {
> duplicate = child;
> }
> }
> }
> if (duplicate != null) {
> StructureModelManager.INSTANCE.getStructureModel().getRoot
().removeChild(duplicate);
> }
> StructureModelManager.INSTANCE.getStructureModel().getRoot
().addChild(cuNode);
>
> And get these kinds of results out:
>
> >> root default.lst kind = java source file child is figures but
sourceloc is null
> java.lang.NullPointerException
> at
org.aspectj.ajdt.internal.core.builder.AsmBuilder.internalBuild(AsmBuilder.java:147)
> at
org.aspectj.ajdt.internal.core.builder.AsmBuilder.build(AsmBuilder.java:64)
> at
org.aspectj.ajdt.internal.compiler.lookup.EclipseFactory.finishedCompilationUnit(EclipseFactory.java:303)
> at
org.aspectj.ajdt.internal.compiler.AjCompiler.process(AjCompiler.java:67)
> at
org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:338)
> at
org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:475)
> at
org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:210)
> at
org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:89)
> at
org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:213)
>
> Is it right that default.lst is considered a java source file? So far,
I've only seen it blow up reporting .lst files as the node it has having
problems with.
>
> It goes wrong like this intermittently, and I've seen the NPE at the same
line (obtaining the sourcefile) in the other place in AsmBuilder.java where
this code fragment is duplicated. The duplicate works at a particular node
in the tree rather than the root.
>
> cheers,
> Andy.
>
> Andy Clement
> AJDT Development
