Why does an `.ino` file have to be in a folder of the same name?

Question

I'm trying to organise a very complicated project and I want to put all the actual code in a folder named src (source), but I want to keep the main .ino file as main.ino (it will also be in src). Then when I try to open the code, the IDE says that main.ino has to be in a folder named main.

Why is this?

I fully understand the error message, but why does the file naming in Arduino has to be so. Is there a way to change that?

Answer 1

AFAIK, that is a quirk built into the Arduino IDE. The best workaround I can think of is a file structure something like:

ArduinoWorkspace --- /myproj/ ----+ /src/ --------+ myproj.cpp
 + myproj.ino + sensor.h
 + sensor.cpp
 + (more files)

, where myproj.cpp just #include's main.cpp. This should leave your project files "clean" such that they should work in a more typical environment as well.

Update:

I borrowed the name "main" from your question, but on reflection, "main" is a reserved name, specifically, every C or C++ program has a main.c or main.cpp as its top level code, provided by the system if you don't provide one. So I avoided using that as the folder- and project-name (but feel free to try it) and I've updated the diagram. What you do need is a project folder and a .ino file within it, of the same name. The .ino file could

#include <src/anything-else-you-like>

, e.g., your top level code file, thus pulling everything else. You may need for your .ino to #include each of the files in the src folder, if it the compiler doesn't figure out on its own, that that's where your other files are.

BTW, if you do use the name main.cpp for your top file, it will have to call the setup() and loop() functions (and serial event function, if you use that). It's probably best to leave the name 'main' alone, let the system provide the same main every Arduino program gets by default, and write your project code the typical Arduino way -- starting with setup() and loop().

• Dat Ha: myproj.cpp, you mean myproj.ino? Because I don't see where myproj.cpp is!
• Dat Ha: Ok, little problem, if I do this, some basic Arduino functions (such as map() and analogRead()) that are contained in sensor.cpp won't be recognize by the compiler.
• st2000: Alternatively, if working on a Windows box, use the junction command and "link" a correctly name directory to the directory with the better name. Or, if working on a Linux box, use the symbolic link command to do the same.
• JRobert: (See my update - your .ino file might have to include each of the other files).
• Eric Duminil: Could you please update your answer? You are mentioning files that are nowhere to be found in your folder structure.

Answer 2

When you have a project made up of a number of .INO files, how is the IDE supposed to know which is the "main" one? During compilation the IDE concatenates all the .INO files together into one monolithic file. It does this starting with the "main" one and then appends each of the others alphabetically to the end.

It is done this way so that your includes and global variables, which you should put in your "main" .INO file, are at the start of the finished program.

In order to do this the IDE has to know which of the files is the "main" one. And the way it works that out is by finding the one which is named the same as the folder the sketch is in.

In UECIDE I take it a step further and turn the whole folder into a compound document so you no longer have to enter a folder and open a .INO file to open a sketch - the actual folder itself is the whole sketch project. Again this kind of folder is identified as having a .INO file within it that is named the same as the folder.

• Andre Holzner: in fact, for me the IDE wants to move the proj.ino file even when it is already in a directory proj/ (and it is the only .ino file in that directory but there are other files in the same directory), i.e. it wants to move it to proj/proj/proj.ino. At some point I'll reach the maximum path length of the file system...
• Andre Holzner: it turns out that in my case I had a few softlinks pointing nowhere in the directory of the .ino file. Removing them seemed to solve the problem...