Arduino compiles with hidden files (.svn)

[spivey]

I have a library in the new format and an example sketch that compiles with Arduino 1.5.4. While doing development, it is nice to test it in its native subversion directory. The trouble is, when the .svn directories exist in the library, something goes horribly wrong with the compile and Arduino tells me that it can't find various include files. If I delete the .svn directories and restart Arduino, then the library example compiles fine. I don't know if this should be called a "bug" or a "feature request" , but it would be awesome if local .svn directories didn't affect the Arduino compile (or any hidden files/directories for that matter).

[ffissore]

Hi @spivey , can you provide a zip with the library and sketch so that I can reproduce the bug? The only thing I see and that needs a fix is that a library with .svn folders will be ignored by the IDE

[ffissore]

Also: which version of the IDE are you using?

[spivey]

I am using 1.5.4.

I have attached a zip file of my Arduino library. The example is
Chirps_Owl->ChirpsOwlDigitalTest. If you copy the contents of the zip file
to the user's Arduino directory and compile, it will flag a compile error.
However, if you remove the .svn files littered down in each directory, then
it will compile fine. So, something with the .svn files is messing things
up.

For the bad compile (with the .svn directories), the initial compile line
is:

C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avr-g++ -c -g -Os -w
-fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p
-DF_CPU=16000000L -DARDUINO=154 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR
-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino
-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard
C:\Users\gspivey\AppData\Local\Temp\build3363443789290255734.tmp\ChirpsOwlDigitalTest.cpp
-o
C:\Users\gspivey\AppData\Local\Temp\build3363443789290255734.tmp\ChirpsOwlDigitalTest.cpp.o

ChirpsOwlDigitalTest.ino:12:25: error: Chirps_Host.h: No such file or
directory

ChirpsOwlDigitalTest.ino:13:28: error: Chirps_Channel.h: No such file or
directory

ChirpsOwlDigitalTest.ino:15:56: error: Owl.h: No such file or directory

And for the good compile (without the .svn directories) the initial compile
line is:

C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avr-g++ -c -g -Os -w
-fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p
-DF_CPU=16000000L -DARDUINO=154 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR
-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino
-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard
-IC:\Users\gspivey\Documents\Arduino\libraries\Chirps_Host\src
-IC:\Users\gspivey\Documents\Arduino\libraries\Chirps_Host\arch\avr
-IC:\Users\gspivey\Documents\Arduino\libraries\Chirps_Owl\src
C:\Users\gspivey\AppData\Local\Temp\build2603853242652762133.tmp\ChirpsOwlDigitalTest.cpp
-o
C:\Users\gspivey\AppData\Local\Temp\build2603853242652762133.tmp\ChirpsOwlDigitalTest.cpp.o

So, when the .svn directories exist, Arduino is not generating the
appropriate include directories so that the compile can find the include
files.

-Gary

On Mon, Oct 14, 2013 at 2:41 AM, Federico Fissore
notifications@github.comwrote:

Also: which version of the IDE are you using?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1619#issuecomment-26245279
.

[ffissore]

Sorry @spivey github does not attach email attachments. Please send it to f.fissore@arduino.cc

[ffissore]

Thank for the email @spivey I've tested the commits above and, a part an initial warning telling you the IDE is ignoring folder ".svn" etc, everything works fine
Pay attention to your code however: as I use llinux, I found a typo repeated here and there: #include "Chirps_Linklist.h" should be #include "Chirps_LinkList.h" (second L upper case)
Tomorrow the newest nightly build will be available and it will include this fix.
Please close the issue as soon as you can confirm it.

[spivey]

Thanks for the help (and I will fix those capitalization things - didn't
know the windows compile ignored them). I have confirmed that the nightly
build works for my case.
This fixes #1619.

-Gary

On Mon, Oct 14, 2013 at 1:08 PM, Federico Fissore
notifications@github.comwrote:

Thank for the email @spivey https://github.com/spivey I've tested the
commits above and, a part an initial warning telling you the IDE is
ignoring folder ".svn" etc, everything works fine
Pay attention to your code however: as I use llinux, I found a typo
repeated here and there: #include "Chirps_Linklist.h" should be #include
"Chirps_LinkList.h" (second L upper case)
Tomorrow the newest nightly buildhttp://arduino.cc/en/Main/Software#toc4will be available and it will include this fix.
Please close the issue as soon as you can confirm it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1619#issuecomment-26284700
.

[ivannunyadambiz]

[edit2: obviously not used to git...]

This bug still is an easy to reproduce bug on Arduino 1.5.4r2 for Windows.
After downloading and installing the mentioned version,
create a folder with the name ".svn" in a library subfolder (like C:\arduino\libraries\AccelStepper.svn) [edit: read AccelStepper\ .svn without space. \ . together results in .].
Then start the IDE.

Symptoms:

• it will not throw an error
• the 'fixed' library containing the .svn folder will not show in the examples menu
• switch to different board throws "Invalid library found in"

Final thoughts:
the .svn folders are all over the place when using tortoisesvn. However the .svn folders anywhere else but the root folder of a 'new spec' Library will be ignored.

We need a way to exclude folders. People using SVN will want the .svn folders to be ignored, but there will of course be other cases.

[matthijskooijman]

I don't think 1.5.4r2 includes the fix. Did you try the nightly build? That one is automatically build from the git version, which should include the fix.

[ffissore]

Indeed, as stated in #1619 (comment), the fix is available in the nightly build and will be part of next, still to be released, 1.5.5
/cc @cmaglie