Non-MBS projects cannot be used as RTE projects

[jesperes]

I tried to use a non-MBS project as a RTE project by calling RteProjectManager#createRteProject on a project with only a RTE nature, but this triggers a NPE in at least one place where ManagedBuildManager#getBuildInfo is expected to return a non-null IManagedBuildInfo:

Thread [Worker-3] (Suspended (exception NullPointerException))  
    ProjectUtils.isExcludedFromBuild(IProject, String) line: 526    
    RteProjectUpdater.addFile(IRteConfiguration, String, ICpFileInfo) line: 418 
    RteProjectUpdater.addResources(IRteConfiguration) line: 354 
    RteProjectUpdater.addResources() line: 341  
    RteProjectUpdater.runInWorkspace(IProgressMonitor) line: 123    
    RteProjectUpdater(InternalWorkspaceJob).run(IProgressMonitor) line: 39  
    Worker.run() line: 56   

The use case we have is that we are trying to create a project solely for the purpose of hosting a RTE configuration, but which will not be used for building using MBS.

[edriouk]

Hi Jesper,

The current implementation of the com.arm.cmsis.pack.project plug-in entirely relies on MBS framework, you can see ManagedBuildManager.getBuildInfo(project) calls in many places. Unfortunately I have not had a look at non-MBS projects yet and cannot offer a plausible solution in the near future. However the com.arm.cmsis.pack.project plug-in is independent from the rest (other plug-ins do not depend on it). Therefore you can create your own project management plug-in that supports new CDT project model. It would be greate if you could contribute your solution to the CMSIS pack plug-ins then.

Best regards, Evgueni

[jesperes]

Ok, thanks. The fastest way to get something which works at the moment is to use our MBS toolchains, but we will be needing support for the new CoreBuild system in the future. Lets keep that thread open.

[jesperes]

I've dug a little deeper into this, and I see that there is a lot of things that the *.project plugin does which is really independent of MBS (for example copying/deleting files, hooking into the RteEvent mechanism, etc), but there is no straightforward way of reusing that code while at the same time avoiding hitting MBS stuff.

As far as I can tell, the only place where the project plugin refers to MBS stuff is in RteProjectUpdater, and even there most of it could just be fixed to allow for e.g. ManagedBuildManager#getBuildInfo to return null. For example, the project updater attempts to invoke the toolchain adapter to set build settings, but for non-MBS projects that step could simply be skipped. For me it is no big deal to have a dependency on MBS, as long as I don't need to go through all of the extra work of creating an MBS-project.

I'll try to fix this by inserting some NPE checks at suitable places, but a better solution would probably be to allow clients to e.g. plugin their own RteProjectUpdater without having to replace the entire RteProject* set of classes.

[edriouk]

Thnak you for looking at that in details. I agree that RteProjectUpdater should be made extendible/overridable. Actually it should take place the RteToolchainAdapter role, updating not only build settings, but files and other user-defined project properties. It would be more flexible. But at the time of creation of *.project plig-in, MBS was the only option. Therefore only RteToolchainAdapter extension point was made.

[jesperes]

Ok, so making RteProjectUpdater handle non-MBS project seems to be a pretty minor change. I'll try to get a pull request for you later today.

[jesperes]

(As a side note, I have two other outstanding pull requests. Could you take a look at them and comment on them?)

[edriouk]

Hi Jesper, as you can see I have merged you last pull request. Next week I'll build and publish version 2.3.1 I have not merget other two of your pull requests since the corrsponding changes are already in the version 2.2.0.

[jesperes]

Excellent, then I will close this issue.

(There are a number of other issues regarding using non-MBS projects, but they could all be worked around on my side.)