Added API to manually run CMake - #1483
Conversation
|
Hi Mr. @betamaxbandit , Before making this PR official, could you take a quick look and let me know what you think? FYI, it built failed due to the removal of Thanks. |
db124ca to
6b81f27
Compare
Hi @DangMinhTam382 , |
Allows ISV to manually run CMake without having to build the project. Moved code to separate method and make a convenience protected for the derived to call.
6b81f27 to
f70ef1b
Compare
|
Hi Mr. @betamaxbandit , I have made some modification to allow manual testing for this PR. Many thanks, |
betamaxbandit
left a comment
There was a problem hiding this comment.
LGTM, just a few minor grammar issues.
|
|
||
| ### 9) CMake configuration | ||
|
|
||
| Verifies that API for configuring CMake could work individually. |
There was a problem hiding this comment.
Verifies that the API for configuring CMake can be invoked independently.
There was a problem hiding this comment.
Thanks for the suggestion! I updated the README.md file
| ### 9) CMake configuration | ||
|
|
||
| Verifies that API for configuring CMake could work individually. | ||
| Note, API could only be test in Developer environment with plug-in **org.eclipse.cdt.cmake.example** included. |
There was a problem hiding this comment.
Note: this API can only be tested in a CDT development environment that includes the org.eclipse.cdt.cmake.example plug-in.
There was a problem hiding this comment.
Thanks for the suggestion! I updated the README.md file
| 1. Remove existing "**/build/**" folder. | ||
| 2. Right click project > select "Configure CMake Project". | ||
|
|
||
| Expected: CMake Configuration process start with active launch settings. |
There was a problem hiding this comment.
- Remove any existing
**/build/**folder. - Right-click the project and select Configure CMake Project.
Expected: The CMake configuration process starts using the active launch settings.
There was a problem hiding this comment.
Thanks for the suggestion! I updated the README.md file
| ILog.of(ConfigureExtendedCMakeProjectHandler.class) | ||
| .error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$ | ||
| } | ||
| return null; |
There was a problem hiding this comment.
runInWorkspace should return an IStatus. Returning null after logging the exception is risky and means the Jobs framework does not receive a proper failure status.
Could this return the CoreException status, or an error status for IOException?
Something like ...
} catch (CoreException e) {
return e.getStatus();
} catch (IOException e) {
ILog.of(ConfigureExtendedCMakeProjectHandler.class)
.error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$
return Status.error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$
}
There was a problem hiding this comment.
Ahh, thanks for pointing this out and the suggestion as well.
I believe the WorkspaceJob does log the error if an error status is return.
So, I grouped them together and return a simple
Status.error(message, exception)
WDT?
| return null; | ||
| } | ||
| }; | ||
| job.schedule(); |
There was a problem hiding this comment.
This job modifies project state: markers, resource refresh, and scanner information. Should it set a scheduling rule before scheduling, probably the project, to avoid running concurrently with other workspace operations on the same project?
Suggestion ...
job.setRule(project);
job.schedule();
There was a problem hiding this comment.
I'm with you on this one.
I'm not quite sure if there's another WS job running during CMake configuration process, so I'll play it safe here and set rule to it as suggested.
| point="org.eclipse.ui.commands"> | ||
| <command | ||
| id="org.eclipse.cdt.cmake.example.configureCMakeProject" | ||
| name="Configure Extended CMake Project"> |
There was a problem hiding this comment.
The menu label says "Configure CMake Project" but the command name says "Configure Extended CMake Project". Could these be made consistent? Unless "Extended" has a specific meaning here, I suggest using "Configure CMake Project" in both places.
There was a problem hiding this comment.
Ah, yes, the initial intent was to allow CMake configuration only for Extended CMake projects.
Later, this was changed to support all CMake projects, and these spots were somehow missed.
Updated the UI and class names to align with the current behavior.
betamaxbandit
left a comment
There was a problem hiding this comment.
Hi,
this is looking really good.
There's a few minor issues that should be resolved please.
a8aa06f to
6314dbd
Compare
DangMinhTam382
left a comment
There was a problem hiding this comment.
Hi Mr. @betamaxbandit ,
I fixed your comments and this should be ready to be reviewed again
Many thanks,
Tam
| return null; | ||
| } | ||
| }; | ||
| job.schedule(); |
There was a problem hiding this comment.
I'm with you on this one.
I'm not quite sure if there's another WS job running during CMake configuration process, so I'll play it safe here and set rule to it as suggested.
|
|
||
| ### 9) CMake configuration | ||
|
|
||
| Verifies that API for configuring CMake could work individually. |
There was a problem hiding this comment.
Thanks for the suggestion! I updated the README.md file
| 1. Remove existing "**/build/**" folder. | ||
| 2. Right click project > select "Configure CMake Project". | ||
|
|
||
| Expected: CMake Configuration process start with active launch settings. |
There was a problem hiding this comment.
Thanks for the suggestion! I updated the README.md file
| ILog.of(ConfigureExtendedCMakeProjectHandler.class) | ||
| .error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$ | ||
| } | ||
| return null; |
There was a problem hiding this comment.
Ahh, thanks for pointing this out and the suggestion as well.
I believe the WorkspaceJob does log the error if an error status is return.
So, I grouped them together and return a simple
Status.error(message, exception)
WDT?
| point="org.eclipse.ui.commands"> | ||
| <command | ||
| id="org.eclipse.cdt.cmake.example.configureCMakeProject" | ||
| name="Configure Extended CMake Project"> |
There was a problem hiding this comment.
Ah, yes, the initial intent was to allow CMake configuration only for Extended CMake projects.
Later, this was changed to support all CMake projects, and these spots were somehow missed.
Updated the UI and class names to align with the current behavior.
betamaxbandit
left a comment
There was a problem hiding this comment.
LGTM
Thanks Tam for reworking this.
I think it's now ready to merge.
| Bundle-Name: %pluginName | ||
| Bundle-SymbolicName: org.eclipse.cdt.cmake.example;singleton:=true | ||
| Bundle-Version: 1.0.0.qualifier | ||
| Bundle-Version: 1.0.1.qualifier |
There was a problem hiding this comment.
Hi Mr. @jld01 ,
Updated the micro version to 100 as suggested.
Just for my understanding, is "increasing micro by 100" always applied? or is it just temporary?
There was a problem hiding this comment.
Thank you for the update, @DangMinhTam382. The CDT project follows the same versioning rules as Eclipse Platform. The bundle micro version is updated by 1 for occasional CDT bugfix releases from an existing release branch (such as CDT 11.6.1). For the regular minor releases (where a new release branch will be made shortly before release), we update the so-called service segment.
Looks like Code Cleanliness Checks / build (pull_request) built failed due to server issue? |
jld01
left a comment
There was a problem hiding this comment.
Bundle version looks good now.
|
Thanks Mr. @betamaxbandit and Mr. @jld01 for reviewing this. Mr. @jonahgraham, could you have a look and merge this one for me? |
Allows ISV to manually run CMake without having to build the project.
Moved code to separate method and make a convenience protected for the derived to call.