Is there a doc that explains the Hierarchy and file structure of the IDE? What I mean is if I don't want to use the "default" location for the installation what things should I be looking for as to how the IDE finds libraries, sketches, etc. I know I can tell it to install in a different path, I also know I can tell it where sketches are to go. What I am asking is are there any concerns other than those to locations? What about adding new boards, in my case Teensy and esp32.
The reason I am asking is I work from several different locations (PC's) and want to keep the environment the same for all so I installed it on a onedrive location and all sketches are also on the one drive. This is not a group, I just have computers around the house, shop, lab, etc and I want the environment to always be the same.
Are there any pitfalls to this. I'm also using IDE 1.8.19 if it makes a difference.
I also apologize upfront if this is in the wrong place for this type question.
well, just installed 2.3.3 and first impression on a scale of 1 to 10 it is a -5 so far. I hate that I am forced to use the lame editor installed. I will greatly miss my vim 9.x editor. After more than 4 decades of using vi and variants the built in editor lacks just about everything except being able to type in code. I am currently trying to findout if has parameters that can be changed....
Well as far as editor goes there is a work around, minimize arduino ide, use vim to edit and save file then compile with the IDE. sort of what I did using "external editor" in the old IDE. rating moved up from -5 to a 1. Many libraries problem still abound thou... still trying to understand how new IDe (and old for that matter) handle files.
When using Arduino IDE 1.x, you can put the IDE into "portable mode". When in this mode, Boards Manager will install Arduino boards platforms under the portable/packages subfolder of the Arduino IDE installation folder:
When using Arduino IDE 2.x, you can configure the location where boards platforms are installed by editing a configuration file. The file is at this path:
C:\Users\<username>\.arduinoIDE\arduino-cli.yaml
(where <username> is your Windows username)
You can open the file in any text editor. The path is configured via the directories.data property of the file. For example, if I changed that line in the file to this:
data: C:\Users\per\OneDrive\Documents\Arduino15
Then Boards Manager will install platforms under C:\Users\per\OneDrive\Documents\Arduino15\packages
I wouldn't consider it a workaround. This is an ideal workflow for using an external editor in my opinion. Yes, it is different from how Arduino IDE 1.x works, but it is an improvement over the primitive and non-standard system used by 1.x where it was necessary to put the IDE into a special mode to do this instead of the IDE recognizing external changes automatically without the need for any configuration.
You don't have to use the built-in editor. You can have your IDE open, edit the sketch files in another editor and the IDE will watch for changes. So when you save the file in the other editor, changes are (nearly immediately) picked up and shown in the IDE's editor.
Tested on a Windows system with Notepad++ and IDE 2.3.3. as well as on an Ubuntu 24.4 system with vi and IDE 2.3.2.
PS
Not 100% sure how the external editor feature in IDE 1.8.19 exactly works; I know it exists but have not really used it.
If I understand what you are wanting, I'm afraid you are SOL.
It used to be that (at least on linux) you could simply extract an IDE image anywhere you wanted, and all the tools you needed to build were under that location.
This was great for regression testing as you could install mutiple versions of the IDE. In fact I have every version of the IDE all the way back to 0013 which was a couple of years before the 1.0 release.
This is no longer true, the IDE will install cores and platforms and tool sets under your home directory. Even worse, the IDE will pick the latest versions of tools and cores so if a platform core installs an updated tool set that tool set can be used across multiple other IDE installations.
It can create incompatibility issues.
IMO, this was a very hard wrong turn in the way the IDE works and it breaks things like being able to do regression testing across multiple IDE versions.
i.e. If I install IDE version A, then Version B and version B updates a toolset, that update can affect builds with IDE version A.
So there is no longer a way to have a fully encapsulated build environment.
I don't think that there is a work around for this behavior.
In your case, the issue will be how to keep all the stuff that IDE stores in the home directory synced across all your machines.
IF all your machines use the same processor and OS, you might be able to get away with a network mounted home directory.
I feel for you, I've wanted to do the same thing for years.
I also find that IDE 1.x suits my needs much better than IDE 2.x for my Arduino library and sketch development.
There are still some things that are still not working or broken in IDE 2.x that I use and would like my library users to be able use. But after a few years of trying to get these issues fixed, I've pretty much given up on ever getting them fixed.
I tend to use IDE 1.x for my active development I then do testing using IDE 2.x
Yeah, it's not that I can't use 2.x, it is mainly that there are some issues in 2.x that make me long for some 1.x capabilities.
In fact I'm having to change one of my libraries because I can no longer do html links in sketch code to the local documentation that is included with the library.
THAT is a PITA and a loss to my library users.
It uses the version of the boards platform the user installed.
It is true that all Arduino IDE 2.x installations use the same set of boards platforms.
I don't follow you. It affects regression testing against multiple versions of a boards platform, but doesn't at all affect testing against multiple IDE versions.
It is possible to install multiple versions of a boards platform, but you must install the additional versions manually (in the hardware subfolder of the sketchbook), using a different vendor folder for each version.
And if they don't, the subject is moot because the tool dependencies of the boards platforms are host architecture-specific.
A specific example was a few years ago, I used the IDE to add h/w support for a new Arduino.cc board. This package also included a new a new AVR core and a new avr-gcc toolset.
This new core and toolset was suddenly being used for other older IDE versions and for other boards.
This core made certain Arduino constants enums rather than simple #defines.
And while it didn't break any of my code, it broke a few other libraries.
i.e. Install support for board B, on IDE version Y
Now code for Board A on IDE version X no longer worked.
The only solution at that point in time was to remove that package.
And yes I know that the enum code in the core was updated to provide compatibility to prevent this specific issue, but still the real issue was that installing a board support package for one board can break things for other boards because there was no way to completely isolate the IDE versions with their associated tools and cores.
IMO, many of these types issues go way back to the decision to not to do builds and updates in place. Things got messy at that point since sketches have to copied over to tmp areas and tools and cores are not installed or updated to where the IDE package was originally installed.
i.e. IMO, things like binary executables should not be under the users home directory they should be under the IDE installation directory.
That way you can create a snapshot of everything that will be used for that specific IDE installation all under a single directory which makes it easy to manage.
I have also seen cases in the past where there were certain bundled library updates that would get installed into the users sketchbook area.
IMO, this is all kinds of wrong since IMO, the user sketchbook area should be for and only for user created sketches and libraries. - NOT for anything related to IDE bundled libraries.
IMO, bundled libraries that need updating should be updated in place under the IDE installation area for that specific IDE version/instance to keep those updates specific to that IDE instance/version.
For example, for testing, I might want to have multiple installations of a specific IDE version but have different updates applied to each.
i.e. be able to do side by side testing of IDE version X with and without certain updates.
Not keeping those updates separate can create a problem since a bundled library pushed in the users sketchbook libraries area can and will be used across ALL IDE versions. (including 1.x and 2.x) So this can potentially create not only unwanted updates to other IDE versions when multiple are installed and sharing the same sketchbook area, but can create library incompatibilities.
And yes I know and understand that the average Arduino user will never experience the types of issues I'm bumping into.
But still, if things had been done differently, theses issues would not occur and certain things in the build system and library location methodology could have been simplified.
Operating system security restrictions and packaging systems make this impossible in many cases. For example, this is not possible to do with a macOS app, or with a Linux AppImage package.
It could be possible if the IDE and its components were actually part of an OS install package and the various IDE components were also other dependent OS packages.
The OS package manager could then handle the updates and install things in "normal" places.
Although this method would not allow the installation of multiple versions.
.