[
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