Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Incremental Compilation problems.

>  I'm
> interested in how you
> control incremental
> compilation without exposing it through projectproperties
> or buildoptions?

I did add it to the build options to enter incremental
mode, and added a new API (buildFresh(..)) for restarting
(batch-build) when in incremental mode.  In Ajbrowser
that API is invoked when holding the shift key down
when building, but I suspect AJDT would have a better UI.

(It's just a first cut; if there's a better scheme, 
let us know!)

Wes

On Wed, 30 Apr 2003 13:57:25 +0100
 "Andrew Clement" <CLEMAS@xxxxxxxxxx> wrote:
> 
> 
> > 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
> 
> 
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev



Back to the top