Absolute vs Relative pathnames

[hreintke]

Not a real issue now (I think) but like to understand.

I was cleaning up sloeber environments which resulted from working on the "clean project issue".
Tried to do that with "just copying" the sloeber directory from test/temp location to the one I always use.
Resulting in include files not found issue. Could not fix that with clean project and/or remove release directory and/or eclipse refresh.
This was due to the usage of absolute pathnames in the compile process.
Did not look into the details (yet) but can you give an indication when/where absolute pathnames are used and whether there is a way to circumvent that ?

Edit :
I even see "old and new" absolute paths being used : c:\temp\sloeber is the old, c:\utilities\sloeber is the new
"C:\temp\sloeber\/arduinoPlugin/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-gcc" -D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-IC:\temp\sloeber\/arduinoPlugin/packages/esp8266/hardware/esp8266/2.3.0/tools/sdk/include" "-IC:\temp\sloeber\/arduinoPlugin/packages/esp8266/hardware/esp8266/2.3.0/tools/sdk/lwip/include" "-IC:\temp\sloeber\/arduinoPlugin/packages/esp8266/hardware/esp8266/2.3.0/tools/sdk/libc/xtensa-lx106-elf/include" "-IC:\Userdata\ESP8266\Projects\Car/Release/core" -c -Wall -Wextra -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -std=gnu99 -ffunction-sections -fdata-sections -DF_CPU=80000000L -DLWIP_OPEN_SRC -DARDUINO=10609 -DARDUINO_ESP8266_NODEMCU -DARDUINO_ARCH_ESP8266 "-DARDUINO_BOARD=\"ESP8266_NODEMCU\"" -DESP8266 -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\cores\esp8266" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\variants\nodemcu" -I"C:\Userdata\ESP8266\Libraries\Sensors" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\Ticker" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\Servo" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\Servo\src" -I"C:\Userdata\ESP8266\Libraries\CommandProcessing" -I"C:\Userdata\ESP8266\Libraries\ESPAsyncTCP" -I"C:\Userdata\ESP8266\Libraries\ESPAsyncTCP\src" -I"C:\Userdata\ESP8266\Libraries\ESPAsyncWebServer" -I"C:\Userdata\ESP8266\Libraries\ESPAsyncWebServer\src" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\ESP8266WiFi" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\ESP8266WiFi\src" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\Hash" -I"C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\libraries\Hash\src" -I"C:\Utilities\sloeber\arduinoPlugin\libraries\ArduinoJson\5.8.4" -MMD -MP -MF"core\time.c.d" -MT"core\time.c.o" -D__IN_ECLIPSE__=1 "C:\Utilities\sloeber\arduinoPlugin\packages\esp8266\hardware\esp8266\2.3.0\cores\esp8266\time.c" -o "core\time.c.o"

[jantje]

When doing things like upgrading copying things around and things do not work any more, the first thing to do is: to goto project properties->arduino see if all is ok. If not fix it and if all is ok select apply.
The reason for full path names has to do with the fact that sloeber needs to "expand" the recipes to do some post processing to make things work. This makes that the "expanded" recipes have full (os dependent) path names.
For more details see https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.core/src/io/sloeber/core/tools/Helpers.java#L1146

[hreintke]

Hi,
Having trouble to get a real clean new sloeber environment.

What I have is :
c:\userdata\esp8266\libraries -> private libraries
c:\userdata\esp8266\projects -> eclipse workspace with projects in it
c:\temp\sloeber -> sloeber environment, fully working

Then I do :
pull latest git, mvn clean verify
copy product/... sloeber to c:\utilities
So I have c:\utilities\sloeber as the new environment
When I start that, I use the c:\userdata\esp8266\projects as the workspace
Then I get the default download of arduino, which I expect from a clean install
In the windows->preferences->Arduino I see I already have the c:\userdata\esp8266\libraries as path defined -> must come from previous installs
I add the esp8266 as board -> gets downloaded correctly.
When compiling projects I see the use of "C:\temp\sloeber\/arduinoPlugin/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-g++" -> from the previous install

Checked several locations but cannot find where the "previous install" information is stored.
Can you tell me where that is ?

[jantje]

In the windows->preferences->Arduino I see I already have the c:\userdata\esp8266\libraries as path defined -> must come from previous installs

I think oomph is the "problem".
I have a love hate relation with oomph.
Check the log and try to see if oomph did something.
Oomph is installed with eclipse (so also with the product) and I didn't find a good way yet to disable/remove it.
I love the installation capabilities of oomph but I hate the recorder.

When compiling projects I see the use of "C:\temp\sloeber/arduinoPlugin/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-g++" -> from the previous install

After doing :goto project properties->arduino see if all is ok. If not fix it and if all is ok select apply?

[hreintke]

OK, next steps are done.

For oomph, can you tell me where to find the log and/or how to create that ?

For wrong compiler path. I found f.e. the C:\Userdata\ESP8266\Projects\Car.settings\org.eclipse.cdt.core.prefs file.
In there the paths for the compilers etc are stored. I would expect that to be a "sloeber generic definition".
Now the version/location of tools used is/can be different for each of the projects.
When updating sloeber/boards environment you need to go along all projects.

I did not notice this before as you mentioned : After doing :goto project properties->arduino see if all is ok Did not "apply" as all was OK. So you need to apply in all cases. Then it updates to the "new compiler paths"

[jantje]

If you do apply you force all settings to be recalculated. If you click OK settings are only reset when there are changes (like going from Uno to yun).
You can easily see that as clicking ok will not enforce a complete rebuild and a apply does.
I'm trying to find ways to improve the "auto recalculation"

For oomph, can you tell me where to find the log and/or how to create that ?

I have seen oomph logs in the standard log file. But they will only appear when the new workspace is created.
Here you can see the settings changed by oomph /.eclipse/org.eclipse.oomph.setup/setups/user.setup

[hreintke]

When you do a setGlobalValue(KEY_PRIVATE_LIBRARY_PATHS, String.join(File.pathSeparator, folderName));
Where/in which location is that value stored ?

[jantje]

You can find it at [workspaces].metadata.plugins\org.eclipse.core.runtime.settings
Note that it is the eclipse api that saves these value, I advice not to mess with these files

[hreintke]

I am not going to mess around with it.
for :

In the windows->preferences->Arduino I see I already have the c:\userdata\esp8266\libraries as path defined -> must come from previous installs

I think explains the reason. It is a workspace setting and I used the same workspace in \temp.. and \utilities..

Do you also save preferences/info outside the workspace

[jantje]

everything in windows->preferences->Arduino is eclipse instance level

[jantje]

Can we close this issue?

[hreintke]

Yes,
I am still looking into this.
Will reopen or start a new when more info/ideas.

[jantje]

Note that moving workspaces, eclipse instances should update these absolute paths now due to #682