Is there a list of "core" libraries that are "built-into" app lab apps?

I don't agree also. Why do we use arduino-cli compile command even though arduino-cli lib command exists?

"Installed" means the library is available for use by any sketch. This is not the case with the libraries you found in that internal folder. It doesn't make sense to say that a dependency specified by a sketch build profile is "installed" because these dependencies are only made available within the isolated dependencies environment used when compiling with the build profile.

Arduino CLI automatically downloads build profile dependencies on demand, so there is no prerequisite to perform an installation, as is the case with the dependencies of sketches compiled without the use of a build dependency.

Thank you for making it clear that the libraries in the internal folder were automatically downloaded and used when compiling sketch, and that they are not built-in libraries.

However, I think these installed libraries should somehow appear in arduino-cli lib list --all command. I think that's how consistent they are in using the command.

Please provide a detailed explanation of the utility you would find in having these libraries included in the lib list output. This information will allow me to understand the use case Arduino CLI is apparently not serving. I might be able to provide a solution that meets your needs.

If these libraries are not shown in lib list --all command, then user may try to install into Arduiono user library area again as I did.

The problem is that those internal libraries are not uninstalled automatically when same libraries are installed at user location.

Why is that a problem? They serve two completely different purposes:

  • Library dependencies specified by the build profile are used when compiling using the build profile
  • Libraries installed via lib install are used when compiling without a build profile.

The point of build profiles is to allow full control over sketch dependencies. Installed libraries are shared between all sketches compiled without the use of a build profile. This means that updating a library for use by one sketch project might break another sketch that was written for the API of the previous version of the library.

In practice, sharing a single installation of a library between all sketches usually doesn't result in any serious problems, so I think it is fine that the community continue with the old shared library installation paradigm. However, you will certainly find some reports of scenarios like the one I described above. The new build profiles system is very welcome to those of us who would like to be able to achieve reproducible builds with our sketch projects. This is the reason why Arduino chose to utilize build profiles in the new App framework. It pairs well with the approach taken for the Python script component of the App, where Docker containers are used to create a controlled environment in which the script runs.

Why do I waste system resources even exactly same versions are installed? If there are any easy ways to check , we wouldn't.

My recommendation is to always use build profiles. Then you avoid the need for any installed libraries.

Essentially, yes. It is not bundled with the platform in the strict sense of the term "bundled":

https://arduino.github.io/arduino-cli/latest/platform-specification/#platform-bundled-libraries

It is rather specified as a dependency of the platform:

https://downloads.arduino.cc/packages/package_index.json

        {
          "libraryDependencies": [
            {
              "name": "Arduino_RouterBridge",
              "version": "0.4.2"
            },
            {
              "name": "Arduino_RPClite",
              "version": "0.3.0"
            },
            {
              "name": "MsgPack",
              "version": "0.4.2"
            },
            {
              "name": "DebugLog",
              "version": "0.8.4"
            },
            {
              "name": "ArxTypeTraits",
              "version": "0.3.2"
            },
            {
              "name": "ArxContainer",
              "version": "0.7.0"
            }
          ],
          "name": "Arduino UNO Q Board",
          "architecture": "zephyr",
          "version": "0.56.0",

[...]

https://arduino.github.io/arduino-cli/dev/package_index_json-specification/#:~:text=package%20is%20installed.-,libraryDependencies,-%3A%20the%20libraries%20needed

That is correct.

Manually "installing" the Arduino_RouterBridge library in your App doesn't have any effect because Arduino App Lab will just remove the entry from the sketch build profile the next time you start the App. That is the "app migration" mentioned in the message you noted:

For example, if I "install" the Arduino_RouterBridge library, then open the sketch project file sketch/sketch.yaml, I see the expected explicit library dependency entries were added:

profiles:
  default:
    fqbn: 
    platforms:
      - platform: arduino:zephyr
    libraries:
      - dependency: Arduino_RPClite (0.3.0)
      - Arduino_RouterBridge (0.4.3)
      - dependency: ArxContainer (0.7.0)
      - dependency: ArxTypeTraits (0.3.2)
      - dependency: DebugLog (0.8.4)
      - dependency: MsgPack (0.4.2)

default_profile: default

However, if I start the App, navigate back to the "My Apps" view, then open the App again (this reload is necessary due to App Lab's editor not reflecting external changes to the file arduino/arduino-app-lab#37), then I see the sketch project file now contains this:

profiles:
  default:
    fqbn: 
    platforms:
      - platform: arduino:zephyr

default_profile: default

As for #include <Arduino_RouterBridge.h>, it is superfluous because the core already contains that #include directive:

The Arduino sketch preprocessor automatically adds an #include directive for Arduino.h to the sketch.

The "Arduino UNO Q Board" platform's Arduino.h file contains this directive for a header file present in the core variant:

And the core variant used by the UNO Q contains a postvariant.h with the following content:

Arduino_RouterBridge.h has an include guard, so an #include directive in your sketch won't have any effect:

It won't do any harm.

I haven't got any list of the library dependencies with --dump-profile:

(.venv) arduino@uno-q2:~/ArduinoApps $ arduino-cli compile --dump-profile blink/sketch/
profiles:
  unoq:
    fqbn: arduino:zephyr:unoq
    platforms:
      - platform: arduino:zephyr (0.56.0)

(.venv) arduino@uno-q2:~/ArduinoApps $ arduino-cli compile --dump-profile -b arduino:zephyr:unoq /var/lib/arduino-app-cli/examples/common/blink/sketch/
profiles:
  unoq:
    fqbn: arduino:zephyr:unoq
    platforms:
      - platform: arduino:zephyr (0.56.0)

sketch.yaml in $HOME/ArduinoApps/blink/sketch:

profiles:
  default:
    fqbn: arduino:zephyr:unoq
    platforms:
      - platform: arduino:zephyr
    libraries:
      - dir: /home/arduino/Arduino/libraries/ArduinoJson

sketch.ino in $HOME/ArduinoApps/blink/sketch:

  1 // SPDX-FileCopyrightText: Copyright (C) ARDUINO SRL (http://www.arduino.cc)
  2 //
  3 // SPDX-License-Identifier: MPL-2.0
  4 #include <map>
  5 #include <string>
  6 #include <utility>
  7 #include <variant>
  8 #include <vector>
  9 #include <zephyr/kernel.h>
 10 #include <zephyr/llext/llext.h>
 11 #include "Arduino_RouterBridge.h"
 12 #include "ArduinoJson.h"
 13 #include "MsgPack.h"
 14 #include "RTC.h"
 ...

I confirm the bug. The Arduino CLI developers are tracking it via this GitHub issue:

I should have taken the time to personally test using the command under these conditions before recommending it to you. I apologize for any confusion caused by my corner cutting.


Until such time as the --dump-profile bug is fixed, please only use arduino-cli compile --dump-profile when a sketch build profile will not be used by the command. As you noted, the command will print an incorrect build profile whenever a build profile is active, which will occur under either of the following conditions:

  • The sketch project file has a default_profile key.
  • A profile is specified via the --profile flag.

In the former case, you should instead use an alternative command to simply display the content of the sketch build profile. The most simple approach is to use cat. For example:

cat "$HOME/ArduinoApps/blink/sketch/sketch.yaml"

If you want to get more fancy, you can use the excellent yq tool to parse the YAML formatted data of the sketch project file. For example:

yq '.profiles.default' "$HOME/ArduinoApps/blink/sketch/sketch.yaml"