Converting a standard (Git imported) project to Sloeber project leaves Sloeber properties (cfg) blank (443). Latest build shows error

[Dowster64]

See further down this issue. #1733 (comment) I have simplified it to isolate the error to the conversion of a general project to a Sloeber project.

Describe your environment
Do you use the Sloeber product or plugin? - This occurs in both the 4.4.3 product and the 4.4.3 plugin (Eclipse 2025-09). However, the latest nightly (or build v5.00 ae0335c ) shows more details about (I assume) the same error.
Sloeber version number
OS: windows 11 (with no other Java JDK installations)
The url of the json that you used to download the platform n/a
A image of the project properties arduino showing the board settings n/a

Describe the bug
A clear and concise description of what the bug is.
After following the video on the steps to import a sketch from git repository and convert the project to a Sloeber project, the error occurs in the Sloeber project preferences. The images are from the plugin in 2025-09:

After OK and clicking Sloeber again:

Using the V5.00 build (which I unfortunately overwrote my recently dowloaded 4.4.3 version directory) with a new workspace, It does show what the issue might be:

To Reproduce
Steps to reproduce the behavior:
Note I followed the steps in the video on improved support for version control. The differences are that I used ssh and Bitbucket, rather than github. The screenshots are just after conversion from a general project to a Sloeber project

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

provide the name of the board and the platform version you are using.
Provide the json url and a screenshot of project properties->arduino

Expected behavior
A clear and concise description of what you expected to happen. From video:

Data to back up your claim
Prior to overwriting my recent 443 install, I took this image. The default board for the Arduino config seems to be the Yun, I wondered if it was just an issue with character sets in the xml (corrupting the config) because the accent wasn't displayed correctly:

Additional context
Note that I started getting the behaviour of some projects having the same missing/corrupted configurations with an older install of 4.4.3 which had previously had no issues (but hadn't been needed for about 6 months) about a couple of weeks ago. I tried to update it (thinking it would fix it?) but it wouldn't work - it seemed to be a Java issue (at least on the update). I then went to a new eclipse install with the plugin and this seemed fine (until errors with library_index.json). I then installed a new copy of 443 from the website and was working with this until I tried to 'improve' my workflow with git for my arduino sketches. In fact it was the first error that prompted me to use my repos for Arduino as well as my other work. I did find some references to the error but no fix and they didn't seem to be triggered by the conversion.
(edit). Here is a link to an issue showing the same problem from a different cause?:
#1666

There are two sketches in my Arduino repo, the shots from each Sloeber install use either one or the other. The repos is organised like the one in the video.

I hope there is a simple work around . Thanks for all your hard work.

[Dowster64]

*** Note this 'workaround' is not yet working in 4.4.3 Plugin with Eclipse - The project conversion 'works' in the sense that the error in cfg is cleared and boards can be selected but none of the Jantje environment variables and others are set for C/C++ settings, hence make can't be found. Also note that as long as better choices are made for the C conversion, the CDT errors on closing disappear. ****

Possibly a work around? This is not fully working using the Current Eclipse plugin (see above). However, it does work in the V5.00 build. Note that the all the process pics are from the current eclipse plugin, except for the V2 Natures conversion error. I went back to my plugin in version too see if it worked there too, and it did (at least for the sloeber board configuration). The reasoning was that SLoeber/Eclipse seemed to have a lingering oldPrjCDesc = null error that I couldn't clear when I was trying to clean up the configuration (without knowing what the error was exactly).

1. Import (re-import) sketch as general project. Note I did this locally after deleting all the files in the local repo that Sloeber/Eclipse had added. This only left the ino file and the .gitignore.

2. After importing like this there was no underlying C info in the configs, so I converted to C/C++ project

3. After converting to C++ project but before trying to convert to Sloeber project:

4. Deal with V2 Natures issue? (remove that V2 Nature) - This is what happens if you try to convert to a SLoeber project without removing it. *** You don't get this problem if you choose better options when you convert to C project ***

5. Ignore the warnings about removing Natures. Remove the V2 Nature (references autotools). Then convert to Sloeber project. This is the happy result (I really didn't want to use platform.io)

In the plugin 4.4.3 with Eclipse 2025-09 the specific C environment variables for Jantje and make are not present after these conversions. Therefore make can't be found. In V5.00 those variables are there (or at least enough to make the project are) The only hiccup in the V5.00 build was (re) attaching the libraries. Once this was done the project does build successfully. There are some funny named configs (Debug GNU) and 5.00 also has a more structured directory e.g. /src folder but I should be using that I guess.

[Dowster64]

Workaround that works for plugin (4.4.3, from the marketplace) in Eclipse (2025-09).

Note this is a workaround for this issue. This issue might not affect everyone.

Prerequisite

For convenience I created a new Arduino project using the bare minimum sample sketch. This had a proper Release configuration and when closed had no CDT language errors.

I used my local git repository and deleted any previous files created by Sloeber/Eclipse. This was to ensure a 'clean' import

Import and conversion process

1. Select Import -> Projects from Git -> Existing local repository -> Import as general Project and select the directory from the Working Tree
2. Inspect the properties. Note no C/C++ properties
3. Convert the project: Convert to a C/C++ project (Adds C/C++ Nature) and deselect specify project type

Note it is possible to select the Sloeber toolchain under project type, but this does not work, and neither does convert to Sloeber work after this.

4. This left a project with an active configuration called Preference Configuration with only CWD and PWD set.
5. Now convert this project to a Sloeber project. You can now select boards and you now have two configurations (added Release) BUT these have both got the same environment variables and not the ones necessary to build with.

6. Create a new configuration - copy from a working Release (I used a known working project - prerequisites) and make active.

7. Re attach libraries Note I had an Automatically import libraries based on includes and I got too many and some wrong ones it was too enthusiastic. This is mentioned in the known problems AFAIK

8. Build. (it built) Hurrah!

[Dowster64]

Reading through again and there is an observation that ArminJo made on #1666 about their esp projects, like once this happened they all showed this error. I didn't get it on all projects but it did seem to persist or be sticky. I didn't get the full error , but whilst trying different things the one mentioning oldPrjCDesc = null seemed persistent

[jantje]

Some questions/remarks
1

After following the video on the steps to import a sketch from git repository and convert the project to a Sloeber project, the error occurs in the Sloeber project preferences.

Is this in V5? This may be a bug in V5; I can't recall testing the convert to Sloeber project in V5.

2
A sloeber V4 project and Sloeber V5 project are 100% incompatible. Please stick to 1 version to avoid confusions and errors.
Obviously they both compile arduino projects so the incompatibility is in the internal Sloeber configuration files not your arduino code.

3
After converting a github project (which does not contain a sloeber.cfg) there will not be a sloeber.cfg file in the project.
The sloeber.cfg file is only created/updated when you enable "save in version control".
Note that due to a bug sloeber.cfg is read and processed even if the option is not turned on.

[Dowster64]

Hi @jantje, on my computer the error was in all three installs I had -4.4.3 downloaded a few days ago due to troubleshooting library problems, 4.4.3 plugin, and later V5.00 build (with that commit) - which overwrote my 4.4.3 (my fault). The only difference was that the V5.00 build showed that there was an 'orphaned configuration. No base extension cfg exists for io.sloeber.core.sketch.0' and showed the Arduino board selection, Compile Options and other options tabs. In my 4.4.3, once this occurs you can no longer see those tags, so no board selection, compile options or other options tabs.

(1) So the bug affects both 4.4.3 (at least on my PC) and V5, the only difference is V5 shows more information and still shows tabs. However, it couldn't be recovered. (3) I will try to just select 'share in version control' in v5 but in 4.4.3 I couldn't get at that check box (see first paragraph)

(2) I keep the projects separate, in two different workspaces. I used a repo with two sketches, I worked on them independently in each install, Okay the git parent directory is shared but deleting all but the repo ino file and .gitignore, and keeping to one sloeber version for each project meant I am not trying to open projects in sloeber from different versions or workspaces.

[jantje]

, Okay the git parent directory is shared

I don't think this will work.

[Dowster64]

Working with V5.00, I created a new BareMinimum based sketch and pulled it to the local git repository. - Just seen your reply, Eclipse specifically encourages (advises) not to put your local git in a workspace, So like your example from the video (I think) it's separate. Each Sloeber project is also imported from a separate real directory (like the repo you forked). And all my Sloeber installs use separate workspaces.

Using Git /eGit - Does that not provide enough separation between directories for versions of Eclipse/Sloeber?

FYI, here is my V5.0 now after trying to convert directly from a general project to a Sloeber project:

I'll delete the V5.00 install and try it again, as that error started (as opposed to the cfg error) after I tried to fix the first one through copying files (which I stopped doing BTW). However, like #1666 once you get an error (in an install) it seems to persist going forward.

This project was able to be converted to a Sloeber project, after it was converted to a C/C++ project

Okay - the .log file in the workspace .metadata dir is useful :-)

[Dowster64]

@jantje. To keep things simple (er!) I now have a completely new install of Sloeber 4.4.3 from C:\Users\steve\Downloads\sloeber-ide-V4.4.3-win32.win32.x86_64 (1).zip . installed in D:\Sloeber-4.4.3. With a new workspace D:\SWS-new-4.4.3

Steps to reproduce error:

1. From new install/new workspace: Create a new General project. Add a file (general.ino) - leave it empty
2. Convert to Sloeber project.
3. core directory appears
4. Error Program "-E" not found in PATH appears at the same time.
5. Inspecting Sloeber properties shows same error screen, which when cleared, does not show any tabs in the Sloeber properties.

Is this Program "-E" not found in PATH - the root cause?

Here is the text of the error:

Description	Resource	Path	Location	Type
Program "-E" not found in PATH	general		Project Properties, C++ Preprocessor Include.../Providers, [Arduino Compiler Settings] options	C/C++ Scanner Discovery Problem

Here is a screenshot from step 5:

[jantje]

I succeeded to reproduce this issue with the last provided steps in V4.
This seems to be a regression.
Workaround (version controlled projects won't work with the default location)
Delete the project but do not delete the content of the project.
Create a new Sloeber project with the exact same name as the deleted project and select to add "no file" as source code.

[Dowster64]

@jantje (at least for the general project example above) If you convert to a Sloeber project a second time, it seems to work. Not sure about the external repo directory based problem yet. Blimey.

Basically:

Steps to reproduce and workaround error:

1. From new install/new workspace: Create a new General project. Add a file (general.ino) - leave it empty
2. Convert to Sloeber project.
3. core directory appears
4. Error Program "-E" not found in PATH appears at the same time.
5. Inspecting Sloeber properties shows same error screen, which when cleared, does not show any tabs in the Sloeber properties.
6. Convert to Sloeber project again
7. Error goes away and Includes directory appears.
8. Sloeber properties now show. -choose a board
9. add content to general.ino to give make something to do
10. Project now builds

Note: This double conversion also works for an imported local git repo directory.
I'm not sure if the order of the creation of the includes dir and the core dir are important. The core dir is a real dir in the workspace and the git dir

[jantje]

This should work now with newly created project.
For these projects the problem was that there were no configurations.
I have not yet tested with github imports or old sloeber projects