Re: [cdt-dev] Custom language.settings.xml file is not allways applied o

["Popescu, Lidia" <lidia.popescu@xxxxxxxxxxxxx>]

Thanks Johan,

 

Your snipped seems to help, same as mine where I just added Thread.sleep() for 5 seconds and re-tried to get the file and boolean value.

But I still have to see if it fixes the problem on someone’s else side, who happens to have it more often.

 

I will let you know then how it goes.

 

Kind Regards

Lidia

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jonah Graham
Sent: Tuesday, December 10, 2019 10:08 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Custom language.settings.xml file is not allways applied on project open

 

Hello Lidia,

 

Unfortunately there are indeed some race conditions in the code - It looks like you have discovered one of them. 

 

If it is a refresh problem, I wonder if doing the below would help. Can you try it?

 

        public static void loadLanguageSettings(ICProjectDescription prjDescription) {
                IProject project = prjDescription.getProject();
                IFile storeInPrjArea = getStoreInProjectArea(project);
+               try {
+                       storeInPrjArea.refreshLocal(IResource.DEPTH_ZERO, null);
+               } catch (CoreException e1) {
+               }
                boolean isStoreInProjectAreaExist = storeInPrjArea.exists();
                if (isStoreInProjectAreaExist) {
                        Document doc = null;

 

Perhaps that will make sure the state of the file is up to date. I am not sure what (negative) side effects there are with doing that here - as a first step it would be good to know if that resolves the issue.

 

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

 

 

On Tue, 10 Dec 2019 at 14:37, Popescu, Lidia <lidia.popescu@xxxxxxxxxxxxx> wrote:

Hello cdt developers,

 

I am investigating an issue that randomly occurs on our side on eclipse for linux, with CDT 9.4.3.

I am trying to reproduce it on windows, latest cdt, but I have a bit different behavior. Could it be a cdt bug ?  a race condition maybe.

 

We are generating programmatically some cdt projects based on existing templates, including the .settings/language.settings.xml files, and leave the project closed after creation.

 

Then, when a project is open, our custom language settings are not always applied, and sometimes even removed.

 

I investigated the problem and I found that

it happens because it sometimes checks too early if .settings/language.settings.xml file exists, maybe before some refresh jobs finishes, and the file is not accessible as a resource, so isStoreInProjectAreaExist=false, and it loads defaults configuration for language settings.

 

The loadLanguageSettings() is called

And it checks

 

loadLanguageSettings () {

IFile storeInPrjArea = getStoreInProjectArea(project);

boolean isStoreInProjectAreaExist = storeInPrjArea.exists();

 

// and based on result it loads default language settigns or custom from existing .settings/language.settings file

if (isStoreInProjectAreaExist) {

                        System.out.println("    >>> Load from xml file"); . . .

} else {

                        System.out.println("   >>> Load default"); . . .

}

}

 

That is a sample of jobs/processes that are running:

 

A bad sample, when our language settings is not applied:

 

 

A good sample when our custom language settings is applied:

 

 

It goes well when the job ‘Discover compiler build-in language settings’ is executed and in Project properties -> C/C++ General -> Preprocessor Include Paths, macros   Page we can see configuration from our custom language.setttings.xml

 

 

I am not sure yet what process it depends on, but if I wait a bit and re-request value for boolean isStoreInProjectAreaExist = storeInPrjArea.exists();, it returns desired true value.

Could you please help me with this?

 

I will try to reproduce it in eclipse oxygen, with cdt 9.4.3 on windows.

 

 

Thank you

Kind Regards

Lidia

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev