No rule to make target Arduino.h

[hreintke]

Running on Windows 8.1, Sloeber git master, Private Hardware Path config.

First compile works OK, after that all compiles fail with :

12:43:25 **** Incremental Build of configuration Release for project c17Test ****
"C:\\temp\\Sloeber\\arduinoPlugin\\tools\\make\\make" all 
make: *** No rule to make target 'C\:\Userdata\ArduinoC17\cores\esp8266/Arduino.h', needed by 'c17Test.cpp.o'.  Stop.
"C:/temp/Sloeber/arduinoPlugin/tools/make/make all" terminated with exit code 2. Build might be incomplete.

12:43:26 Build Finished. 0 errors, 0 warnings. (took 359ms)

Deleting the Release folder makes it work again but makes it compile full platform.

Checked this private path with others and cannot find a difference.

To rule out boards.txt and platform.txt issues, I tried using the ones from a working environment -> no difference.
I did remove the sloeber.boards/platform.txt to make it use the new ones.

Any idea where to look for a possible wrong configuration ?

[jantje]

I have never seen something similar.
My 2 cent: Make tells you that in order to make the target "all" (which is the make command sloeber uses to build the elf file) the "rule" to "make" target c17Test.cpp.o (In Sloeber this should be based on c17Test.cpp) is dependent on C:\Userdata\ArduinoC17\cores\esp8266/Arduino.h (which is expected).
What is strange is that make tells you it doesn't know a "rule" to "make" target C:\Userdata\ArduinoC17\cores\esp8266/Arduino.h
In Arduino world .h files are not "build" so they are not targets and do not need a "rule" for creation.

My first thinking is:

1. have you been playing with the file types?
2. Does the file C:\Userdata\ArduinoC17\cores\esp8266/Arduino.h exist?
3. Use version control to check recent changes in Sloeber.

To investigate you should get a copy of the working makefile and a copy of the non working makefile and compare.

[hreintke]

Still investigating.

1/ No not anything
2/ Yes
3/ Done, now reverted to the version I was already using from mid may (after #1182 )

What I did :

Instead of private hardware path, use boardmanager to install -> rule out issues on that
Using a empty, newly created project.

What I see :
When the "release folder" is absent, all compiles and uploads OK
When release folder is present -> always have the above error message.

Then :
Stopped sloeber. Using windows cmd in release directory.
Running sloeber make (GNU Make 3.82.90, Built for i686-pc-mingw32-> issue
Running other make (GNU Make 3.81, This program built for i686-pc-msys) -> compiles
When I replace sloeber make by my make -> make crashes on build.

Other :
Works OK within Arduino IDE.

[jantje]

Stopped sloeber. Using windows cmd in release directory.
Running sloeber make (GNU Make 3.82.90, Built for i686-pc-mingw32-> issue
Running other make (GNU Make 3.81, This program built for i686-pc-msys) -> compiles
When I replace sloeber make by my make -> make crashes on build.

I'm not fully understanding what you exactly did in the last line.
It is important that the make in arduinoplugin/tools/make has all needed components.
This is so because there have been many instances where there was conflict between os installed stuff and Sloeber. Therefore on windows sloeber replaces the path with
${A.COMPILER.PATH}${PathDelimiter}${A.BUILD.GENERIC.PATH}${PathDelimiter}${SystemRoot}\system32${PathDelimiter}${SystemRoot}${PathDelimiter}${SystemRoot}\system32\Wbem${PathDelimiter}${sloeber_path_extension}
Sloeber calls make with a fqn. you can change that in project properties->C/C++ build->build command. remove the ${JANTJE.MAKE_LOCATION}
If you set sloeber_path_extension in windows->preferences->C/C++->build->environment to ${PATH} and remove ${JANTJE.MAKE_LOCATION} you should get the same behaviour in Sloeber as running make in cmd
(make sure project properties->C/C++ build->"expand Env. variable refs in makefiles" is set to true!!!)

To investigate you should get a copy of the working makefile and a copy of the non working makefile and compare.

Did you do this investigation step?

[hreintke]

Did you do this investigation step?

Yes I did. Paths and some files differ as expected between two platforms.
No indication to Arduino.h in both. Maybe I make a new platform location and copy the ones I investigate in (one by one).
The it could be even clearer in differences.

If you set sloeber_path_extension in windows->preferences->C/C++->build->environment

In than location I see only the a.runtime.tools.... defined. I can see the use of sloeber_path_extension in the path but nowhere the
definition of it.

[jantje]

In than location I see only the a.runtime.tools.... defined. I can see the use of sloeber_path_extension in the path but nowhere the
definition of it.

sloeber_path_extension is by default not used. As a user you can use it to extend the path. So yes it is not set. you need to add it.

[hreintke]

Made progress, found the way to get the verbose debug output of make.
I use the make that is included in Sloeber.

Partial ArduinoC11 output

  Considering target file '..\T1.h'.
   Finished prerequisites of target file '..\T1.h'.
  No recipe for '..\T1.h' and no prerequisites actually changed.
  No need to remake target '..\T1.h'.
  Considering target file 'C:\temp\ArduinoC11\cores\esp8266/Arduino.h'.
   Finished prerequisites of target file 'C:\temp\ArduinoC11\cores\esp8266/Arduino.h'.
  No recipe for 'C:\temp\ArduinoC11\cores\esp8266/Arduino.h' and no prerequisites actually changed.
  No need to remake target 'C:\temp\ArduinoC11\cores\esp8266/Arduino.h'.
  Considering target file 'C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/stdlib.h'.
  .....
 continuing building

Partial ArduinoC17 output

    Considering target file '..\T1.h'.
   Finished prerequisites of target file '..\T1.h'.
  No recipe for '..\T1.h' and no prerequisites actually changed.
  No need to remake target '..\T1.h'.
  Considering target file 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h'.
   File 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h' does not exist.
   Finished prerequisites of target file 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h'.
  Must remake target 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h'.
make: *** No rule to make target 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h', needed by 'T1.cpp.o'.  Stop.

The difference is in :
C11 Considering target file 'C:\temp\ArduinoC11\cores\esp8266/Arduino.h'.
vs
C17 Considering target file 'C\:\temp\ArduinoC17\cores\esp8266/Arduino.h'.

An additional / in C:\

I cannot find a reference to Arduino.h in the makefile.
Do you have an idea where this can come from ?

edit : Output can be created by changing Build command to ${JANTJE.MAKE_LOCATION}make --debug=verbose in project properties

[jantje]

This looks like we finally found a lead to get to the issue.
I'll check here what I get. Can you tell me the exact difference between
I assume ArduinoC11 is Sloeber git master, Private Hardware Path config with Sloeber make
What is ArduinoC17?

[hreintke]

temp/ArduinoC11 -> My fork of esp8266 arduino, couple of commits behind origin git head
temp/ArduinoC17 ->
It is from an esp8266 maintainers fork,.
The branch where a new toolchain is implemented. The new toolchain supports c++17.
https://github.com/earlephilhower/Arduino/tree/gcc9.1

There is also an alpha 0.0.2 esp8266 version which includes the new toolchain and boardmanager config. That has the same issue.

In the test environment I took a fresh sloeber install (git head) and new workspace.
Both C11 & C17 are used by private hardware path.
I named them ArduinoC11/C17 to be able to compare makefiles etc more easy.

[jantje]

I think I understand what is going on
The first build the make creates for each *.cpp file a *.cpp.d and *.cpp.o file (both files are created with the gcc compiler).
With the next build for each *.cpp file the matching *.cpp.d file is checked to see if it is needed to buiild the *.cpp file
It seems like the gcc compiler you have creates *.cpp.d files that are incompatible with the make Sloeber is using( C:\ versus C:."

If my understanding is correct, the community that maintains the gcc compiler should be able to tell you which make is working for their gcc compiler. At least a issue should exist for this incompatibility with mingw32

To verify my assumption: Can you check a *.cpp.d file for C:\ occurrences ?

[hreintke]

Nice catch. Think you are right.
This is the start of T1.cpp.d ->ArduinoC17

T1.cpp.o: ..\T1.cpp ..\T1.h C\:\temp\ArduinoC17\cores\esp8266/Arduino.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/stdlib.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/machine/ieeefp.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/_ansi.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/newlib.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/sys/config.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/sys/features.h \
 C\:/temp/ArduinoC17/tools/sdk/libc/xtensa-lx106-elf/include/xtensa/config/core-isa.h \

This is the start of T1.cpp.d ->ArduinoC11

T1.cpp.o: ..\T1.cpp ..\T1.h C:\temp\ArduinoC11\cores\esp8266/Arduino.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/stdlib.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/machine/ieeefp.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/_ansi.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/newlib.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/sys/config.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/sys/features.h \
 C:/temp/ArduinoC11/tools/sdk/libc/xtensa-lx106-elf/include/xtensa/config/core-isa.h \

I will contact esp8266 team and report back here.

[hreintke]

In generic terms I asked ;

Is there a way to revert to the old format ?

This is the reply from esp8266/arduino

That's pretty strange. It's not a dependency format so much as an escaping of paths issue. I doubt there's anything you can do to make GCC not escape the colon in makefiles.

What make version do you have installed? Looking thru gnu.org I can see in gcc 4.x has an unescape_char(...,':') in the depfiles parser, but that is not present in the 3.x branch. No guarantees this fixes your problem, but it does look very promising.

The make that soeber uses is 3.82.

I downloaded make 4.3 from https://github.com/mbuilov/gnumake-windows (just a google search result, no other reason for choosing this one).
That works at first sight but no specific testing done.
I don't know from where make for windows can/should be downloaded.

I can test for you. Just let me know what/how you like to test/proceed.

[jantje]

That's pretty strange. It's not a dependency format so much as an escaping of paths issue. I doubt there's anything you can do to make GCC not escape the colon in makefiles.

Well this is the first time this gets reported for Sloeber. There are 700+ boards. Probably 30+ gcc flavours ...

There is no make for windows. There are many options and this is why Sloeber provides its own because they all behave differently.
The make that sloeber uses is from mingw32. As eclipse no longer provides 32 bit versions and mingw no longer creates new 32 bit versions, I may switch to mingw 64 bit but that means lots of testing.

[jantje]

I ran a test with a newer make. The one from mingw 64.
The compile default ino was successful on 708 boards.
You could try this one, though I'm convinced the : is an error of the gcc compiler

The make I tested can be found here: http://www.baeyens.it/eclipse/download/makeV2.zip
I advice to rename arduinop¨Plugin/tools/make to arduinoPlugin/tools/make.org
and extract the makeV2.zip in arduinoPlugin/tools

[hreintke]

Maybe because of the bleeding edge gcc 10.1 toolchain which will be used in their next 3.0 release.

For now I am using the gnumake 4.3 a mentioned before without any problems, but I am no way representative for the world out there.

I can help you testing this/others if you want .
I am on Windows 8.1 (possible Win 10 in some time but not sure yet).
Have atmega328, attiny, esp8266, esp32

Edit : crossing comments. I'll try the one you mentioned.

[hreintke]

I am using your makeV2 version now in my environment.

Don't have the original issue anymore, all other still work -> looks OK.
I'll keep using this and report if I see missing/faults.
If you want me to do additional/specific tests, just let me know.

Checked (and will do more) changelogs of the toolchain but could not find a note related to the .d file fomat.

The compile default ino was successful on 708 boards.

Not sure how you tested but initial build was working OK, Issue was when doing an incremental build.

[jantje]

Not sure how you tested but initial build was working OK, Issue was when doing an incremental build.

Here is the test I use https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.tests/src/io/sloeber/core/CreateAndCompileDefaultInoOnAllBoardsTest.java
This indeed does not cater for rebuild related issues. However if rebuild works for one of the existing compilers and for your : compiler I think it is safe to assume it works for all compilers

[hreintke]

I have this make now running for multiple platforms, no issues seen.

I'll leave it to you to close the issue or keep it open for reference.

Thanks for helping.

[jantje]

I'm keeping it open to move to the newer version of make

[BriscoeTech]

Thank you both for figuring this out. This was going to be my next bug to try and describe but you beat me to it.

I was noticing it was orphaning files in the release folder when removing or changing linked resources, or when changing a projects board type. I do alot with the samd21 and samd51, and sometimes I make a copy of a project just to change its board type and would run into this issue. It was becoming a habit that whenever I changed anything in the project settings, I was preemptively deleting the release folder to avoid this.

Just to clarify, is the current workaround to replace the make.exe found at sloeber\arduinoPlugin\tools\make\make.exe to one of the executable found here? https://github.com/mbuilov/gnumake-windows

[jantje]

I don't now the repository you refer to. I also don't think it will fix the issue.
The difference between the 2 make.zip files (except for maybe a newer version and 32 versus 64 bit) is that "new" one contains sh.exe

[BriscoeTech]

I am using the Adafruit Samd v1.5.11 repository for M0 feather and M4 feather boards.

I am trying to recreate the problem consistently and I cannot seem to do it. It creeps up usually when sharing version controlled projects between people, will see if I can make something that does it reliably.

[hreintke]

Hi,

Using the make from http://www.baeyens.it/eclipse/download/makeV2.zip

Breakes the fix for #1166

using makeV2 :

Must remake target 'pre-build'.
cmd /c if exist "C:\Userdata\ESP8266\Projects\DualSteer\partitions.csv" copy /y "C:\Userdata\ESP8266\Projects\DualSteer\partitions.csv" "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv"
Main thread handle = 0000000000000078
cmd /c if not exist "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv" copy "C:/Userdata/ESP32/arduino_esp32\tools\partitions\default.csv" "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv"
The syntax of the command is incorrect.
make[1]: *** [makefile:112: pre-build] Error 1
make: *** [makefile:72: all] Error 2
"C:/Utilities/Sloeber/arduinoPlugin/tools/make/make --debug=verbose all" terminated with exit code 2. Build might be incomplete.

using make orig

Considering target file 'pre-build'.
 File 'pre-build' does not exist.
 Finished prerequisites of target file 'pre-build'.
Must remake target 'pre-build'.
cmd /c if exist "C:\Userdata\ESP8266\Projects\DualSteer\partitions.csv" copy /y "C:\Userdata\ESP8266\Projects\DualSteer\partitions.csv" "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv"
Main thread handle = 00000094
cmd /c if not exist "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv" copy "C:/Userdata/ESP32/arduino_esp32\tools\partitions\default.csv" "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv"
        1 file(s) copied.
' '
Successfully remade target file 'pre-build'.

[jantje]

I don't think this has to do with #1166 because the command seems correct to me.
I think sh has a problem with the second command
cmd /c if not exist "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv" copy "C:/Userdata/ESP32/arduino_esp32\tools\partitions\default.csv" "C:\Userdata\ESP8266\Projects\DualSteer\Release\partitions.csv"
I think the mix of \ and / is the root cause.

[hreintke]

I referred to #1166 because the make.exe I use is the one which solves that issue.

Is there a different sh.exe used by each of the make.exe's ?

[jantje]

I am all confused right now. #1166 does not mention make
it is about { being converted to {

[hreintke]

Sorry for the confusion, I mixed up PR numbers. Maybe the current temperatures affecting my brain.

Indeed this Issue #1198 is about the make version. I am using the make from http://www.baeyens.it/eclipse/download/makeV2.zip

When using this make, I have similar symptoms as in #1166 -> the make fails with message The syntax of the command is incorrect.;

When using the make from the distribution (git master) the make runs OK.

[hreintke]

You are right on the / \ root cause.

The issue is in the {runtime.platform.path} which contains forward slashes.
When manually changing that to backward slashes, the make completes correct.

[jantje]

This is one of the reasons why I didn't go to the sh yet in the make.zip
I need to redo al the testing and find fixes but I'm kind of stuck due to #1204 because I may have to undo pull request #1201

[jantje]

The issue is in the {runtime.platform.path} which contains forward slashes.

Can you check with the nightly if #1231 fixed our issue?

[hreintke]

I can, but do not know where to find the windows nightly.

Tried to build from git master but that failed so cannot take that one for this test.

[jantje]

The build of gitmaster should be fine. You do need to switch to the newest maven and java10
Java 10 is also required when upgrading using the nightly
http://eclipse.baeyens.it/nightly.php
I need to add that to the update page :-S

[jantje]

I don't know why this is not logged here but I did switch to the make+sh version.
Still fighting project properties arduino with multiple configuration issues :-(