Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added feature to generate compile_commands.json file #692

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

alicetrifu
Copy link

@alicetrifu alicetrifu commented Feb 5, 2024

Added a new generator class to provide a compile_commands.json file in the "build" folder. Created a new extension point to provide the opportunity to incorporate additional information into the file.

Part of #689

@Kummallinen Kummallinen self-assigned this Feb 5, 2024
Copy link
Contributor

@Kummallinen Kummallinen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick initial pass

You also need to get your API baseline set correctly, as there mare API changes here so you need feedback from the API tooling to get the versions set correctly & all appropriate since tags in place

@Kummallinen
Copy link
Contributor

Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have marked as Resolved those previous comments that seemed complete

Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code cleanliness failed, but not because of this PR. Once I merge #699 you will need to rebase this change.

Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have done a partial review - there are still some concerns I have on the generator that I need to look at a little closer.

Comment on lines 50 to 51
factoryExtensions = new HashMap<>();
loadedInstances = new HashMap<>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I marked previous comments resolved around these fields because they weren't appearing on the latest patchset.

These fields lifecycle is unclear, made more complicated by the local variable with a similar name in initialise method.

Can these fields be final, assigned at declaration and have a clearer lifecycle? If my comment is unclear, let me know and I will provide a commit to explain it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope this is what you've meant, Jonah. If not, please let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is part of what I meant - I will add a commit to this PR to explain explicitly what I mean.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added b6c8e30 which shows what I meant. It is fairly minor, but removes some code and gets rid of the extra temporary map.

jonahgraham added a commit to alicetrifu/cdt that referenced this pull request Feb 12, 2024
Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure at what step we need to add some tests for this. In the meantime, this change (probably because we generate into "new" directory build) causes a test failure in org.eclipse.cdt.managedbuilder.core.regressions.Bug_303953Test.testBuildAfterSourcefileDelete() Please see this section of the testing document for how to run these tests in the dev environment.

@jonahgraham
Copy link
Member

Following our call yesterday we decided that a bit of work is needed on enabling the feature. Quoted from minutes:

One aspect where a decision agreed (with only minor reservations) by all in attendance is to enable the generator by a workspace preference that is disabled by default, with an API to allow CDT-LSP and other dependent projects (such as Renesas' internal editor) to enable it.

@alicetrifu alicetrifu force-pushed the compilationDatabaseGenerator branch 2 times, most recently from 743ca47 to a3198c3 Compare February 21, 2024 14:04
@jonahgraham
Copy link
Member

Following our call yesterday we decided that a bit of work is needed on enabling the feature. Quoted from minutes:

One aspect where a decision agreed (with only minor reservations) by all in attendance is to enable the generator by a workspace preference that is disabled by default, with an API to allow CDT-LSP and other dependent projects (such as Renesas' internal editor) to enable it.

This has grown in scope - in light of our call today and the comment that @15knots made: #689 (comment) we do indeed need this to be settable with the default being the workspace setting. The workspace setting default should be off for now.

@jonahgraham
Copy link
Member

We are going to hold off merging this until after we branch. We plan to branch very soon, a little earlier than normal.

@jonahgraham
Copy link
Member

The conclusion of the meeting today is that the current location for generation (in CommonBuilder) is a reasonable short term solution. There may be better places in the future to keep the compile_commands.json more live, but that is deferred and won't hold up the merging of this change.

Similarly the placement of the output in build/compile_commands.json is a reasonable place for now, but during the meeting we made note that improving the flexibility in clangd may be best here. See also #689 (comment)

*
* SPDX-License-Identifier: EPL-2.0
********************************************************************************/
package org.eclipse.cdt.managedbuilder.core.jsoncdb.generator;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this isn't being exported probably should name this package as an internal. so "org.eclipse.cdt.managedbuilder.internal.core.jsoncdb.generator"

@alicetrifu alicetrifu force-pushed the compilationDatabaseGenerator branch 2 times, most recently from f7eb2c8 to 224f231 Compare March 5, 2024 11:01
@alicetrifu
Copy link
Author

Hello @jonahgraham ,
I've developed a small test suite for functionality validation. I aimed to verify that the functionality applies correctly to CPP projects as well, and to achieve this, I added a new project to the regression workspace and used that in my test. Unfortunately, this test is causing an error during the test execution process along with the build procedure, here on GitHub.

On isCPPFileAllowed (org.eclipse.cdt.managedbuilder.core.tests.CompilationDatabaseGenerationTest) with error
test-results/build/org.eclipse.cdt.managedbuilder.core.tests/target/surefire-reports/TEST-org.eclipse.cdt.managedbuilder.core.tests.CompilationDatabaseGenerationTest.xml [t
I see the following error:
Contains: Errors running builder 'CDT Builder' on project 'helloworldCPP'.
java.lang.NullPointerException: Cannot invoke "org.eclipse.cdt.managedbuilder.core.IOutputType.getOutputExtensions(org.eclipse.cdt.managedbuilder.core.ITool)" because "outType" is null

It's worth mentioning that I never encountered this exception in the workspace, the output is always different from null. Do you have any suggestions on how I could address this issue, maybe? Currently, I've marked the test as skipped, but I believe this should be investigated further in the future.

Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very close to me. I am about to merge in 11.6 version bump now that I have branched for 11.5. I'll try rebasing and see if I can reproduce the difference.

* @throws CoreException
*/
@Test
@Ignore("This will be temporary skipped due to builder error")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The difference between what you see in the workspace and what happens on the build machine is probably down to different sets of enabled bundles. See https://github.com/eclipse-cdt/cdt/blob/main/TESTING.md#using-limited-sets-of-plug-ins-in-tests (point 3)

Builder. Created a new extension point to provide the opportunity to
incorporate additional information into the file
generation on false by default.
Added JUnit test to test the generation of the file
Copy link
Member

@jonahgraham jonahgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The preferences page does not work. The performApply calling itself makes it fail catastrophically, but my attempt at the simple fix did not resolve the issue.

I made comments in the PR for most of the changes I made. I'll mark them as resolved, but wanted you to know why I changed what I did.


@Override
public void performApply(IProgressMonitor monitor) throws CoreException {
this.performApply(monitor);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what intention was here, but this calls itself and causes stack overflow. (Probably should do what is in the listener on line 71)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made this change, but the new code needs to be checked that it is correct.

generateFileCheckbox.setText(Messages.JsonCdbGeneratorPreferencePage_generateCompilationdatabase);
generateFileCheckbox.addListener(SWT.Selection, e -> {
boolean newValue = generateFileCheckbox.getSelection();
preferenceStore.setValue(ENABLE_FILE_GENERATION, newValue);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets avoid changing the preference until Apply is pressed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made this change, but the new code needs to be checked that it is correct.

@jonahgraham
Copy link
Member

Seeing as this implementation the preferences don't work, some additional time is needed here.

I spent some time trying to replicate how @ghentschke and @ruspl-afed implemented preferences for cdt-lsp (e.g. EditorOptions and related classes). That implementation is a little complicated, but does allow all the configuration by products needed. (Unfortunately I ran out of time to do this before I went on vacation)

@jonahgraham jonahgraham force-pushed the compilationDatabaseGenerator branch 4 times, most recently from e58842f to 36aceae Compare March 11, 2024 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants