Include a solution/project file

[lafrank]

Describe the request

A multi-file arduino project is impacted by current implementation of how INO files are concatenated to form a single code space.
A descriptor file should be included with the proejct - just like sln or proj files for Visual Studio - to describe dependencies.
Such a descriptor file would be a great achievment to have control over files arbitrarily dropped into a folder.

Describe the current behavior

INO files in a folder concatenated in alphabetical order.

Arduino IDE version

2.0

Operating system

Windows

Operating system version

10

Additional context

For reference, have a look at Visual Studio (not VS Code !) project and solution files architecture.

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the latest nightly build
• My request contains all necessary details

[kittaakos]

Thanks for taking the time and submitting this enhancement ticket.

A multi-file arduino project is impacted by current implementation of how INO files are concatenated to form a single code space.

What do you mean by current implementation? Here is the specification on how the builder API transforms the sketch files (.ino) into one single .cpp file. The sketch file concatenation is deterministic and is not an arbitrary "current" implementation-dependent logic.

A descriptor file should be included with the proejct - just like sln or proj files for Visual Studio - to describe dependencies.

Please elaborate on what dependencies should be declared in this file.

Such a descriptor file would be a great achievment to have control over files arbitrarily dropped into a folder.

What do you want to control here? Can you tell us more about your use case? What drop-in files are you referring to? What problem would it solve if the sketch file concatenation could be controlled with such a project file?

Thank you!

[lafrank]

Thanks for looking into this topic and sorry for ambiguity, let me clarify shortly. At the moment - to my knowledge - the builder is enumerating and concatenating INO files in the given folder alphabetically, based on the file names. For this very reason, I have seen multi-file projects where INO file names are prepended with a_, b_, c_ etc, just to tell the builder the order, which is obviously not too elegant and also confusing. What I am suggesting is to have some sort of a project file, which. at its very basic implementation serves two purposes: 1 : list the files that is considered the part of the project, eg: what the builder should enumerate 2 : determine the order of these files (build-order) It is common to some other languages too, that a folder content and folder hierarchy within is considered to be the metadata used to organized files into namespaces, and also assuming that all files is also part of the project. While this approach looks straightforward for the first glance, but it is causing portability issues and file system dependency. Declaring the source files that contributes to the project has also the advantage to avoid situations where a file is copied to a project folder accidentally, and the builder - assuming the file belongs to the project - includes it, causing headaches later. So what I am suggesting instead is a simple (Json, xml, whatever) project file to fully decouple logical structure of a project from the file system structure. With Arduino IDE 2.0, the only viable option for a multi-file project is as follows: - separate the project to multiple header files (with the implementation, too), each spanning a single logical code domain, - add a dummy INO file which only has the includes *in the right order (isn't it the project file actually :-) ?)* Thank you.

[per1234]

Thanks for your suggestion @lafrank.

What I am suggesting is to have some sort of a project file, which. at its very basic implementation serves two purposes:

1 : list the files that is considered the part of the project, eg: what the builder should enumerate
2 : determine the order of these files (build-order)

This would be a fundamental change to the Arduino sketch format. We need to consider the entire ecosystem, which includes multiple development tools and tool versions. If we implemented such a change in Arduino IDE only, this would result in the creation of sketches that are incompatible with other tools and even versions of Arduino IDE.

In addition, we need to consider beginner friendliness. The system you propose significantly increases the complexity of what is currently a fairly intuitive system (all code files shown in the IDE are part of the program and concatenation is done in the same order as the editor tabs).

We have decided that the benefits of the proposal don't outweigh these harmful effects so we are declining it.

For simple project where you want to break the sketch up into a few .ino files, the technique you described of using prefixes on the additional .ino files to influence the order of concatenation will be fine.

For more complex projects, the code should be separated into .cpp and .h files, as you described. No concatenation is done on these files, so the sketch developer is free to name them as they like.

avoid situations where a file is copied to a project folder accidentally

Based on over a decade of supporting Arduino users, I don't think it is a common problem. And the type of user who is incautious enough to accidentally copy code files into their sketch is likely to be the same type of user who would not use the advanced system you propose.

Rather than us providing a workaround to allow such sloppy project management, it will be better for the user to simply remove the unwanted file from their project.

A descriptor file should be included with the proejct - just like sln or proj files for Visual Studio - to describe dependencies.

The ability to manage dependencies on a per-sketch basis is something that would be very beneficial, and is much requested. However, since this was not the primary focus of your request, I'll close this in favor of another issue that we are using to track that request: #2573