GitLab

* Revert "Add macro -DARDUINO_LIB_DISCOVERY_PHASE during lib discovery phase (#633)"

This reverts commit 985b2c99.

* Set {build.library_discovery_phase} to 1 during lib discovery

Previously we used to add `-DARDUINO_LIB_DISCOVERY_PHASE` to the gcc
command line but this produced some incompatiblity with compilers using
non-standard `-d` flag instead of `-D`:

https://github.com/arduino/arduino-cli/pull/633#issuecomment-659529026

* Move precompiled library file location documentation to dedicated section of library specification

As more documentation is added about precompiled libraries, it becomes increasingly awkward to fit in in the bullet list format of the library.properties fields section of the library specification. The specification has a dedicated "Layout of folders and files" section, which is an appropriate place to move the documentation of the precompiled binary files used with this feature. This allows the documentation of the `precompiled` library.properties field to be only about the use of that field, with a link to the section which contains the documentation about the files.

* Document floating point ABI configuration folders for precompiled libraries

These properties were previously undocumented.

Previously, the precompiled field of library.properties only supported one value: "true". As it became apparent that there were two distinct use cases for this feature, it was necessary to add a new option so that both use cases could be fully supported.

ArduinoCore-API is an important resource for core authors, so it is beneficial to alert the readers of this section of the Arduino platform specification to its existence.

By default, Cobra automatically adds a date stamp to the generated command line reference content. Having a date stamp is not necessarily a bad thing, though it's also doubtful that it is useful enough to justify its presence. However, the formatting of this date stamp causes it to be shown as an item in the table of contents of each command reference page, inappropriately located under the "SEE ALSO" heading. This clutters up the documentation without providing any benefits at all.

Fortunately, Cobra has provided an option to disable this behavior: https://github.com/spf13/cobra/blob/master/doc/README.md#disableautogentag

The pymdownx.magiclink Python-Markdown extension adds support for GitHub-style auto-linked issue/PR/commit/user references. In order for the issue/PR/commit references to work correctly in the case where no repository is specified, the extension must be configured with the owner and repository name of the repository that is using it. As a result of not having been updated after it was copied, the extension was previously configured for the squidfunk/mkdocs-material repository, which would result in any references that didn't specify a repository to be relative to that repository, rather than arduino/arduino-cli.

The previous description made it sound like a convenience feature, with the build.board property only needed if you prefer a custom value for some reason. However, the resulting warning can cause confusion and act as a "red herring" for users of board definitions that don't define a build.board property.

* Document how the `packager` value of a tool reference is defined

Referencing tools from another package is any important concept for platform authors to understand. Previously, you had to guess as to what the "packager" value of a tool reference is, which was not obvious due to it being defined outside the tool's definition, and thus not mentioned at all in the "Tools definitions" section of the specification, which is the obvious place to look for this information.

The situation is made more complicated by the fact that what is called "packager" in a tool reference is referred to as "vendor" everywhere else in the documentation.

* Make it clear that tool references in package index result in installation

The platforms containing referenced cores, variants, and even tools in the case of manual platform installation, must have been installed. This could lead a platform author to think the same applies to the tools referenced from other packages by the platform's toolsDependencies field in package_index.json and that this results in their platform having a dependency on the other package's platform which uses the tool.

* [skip changelog] Add linting/formatting tasks and CI checks for docs and config files

* [skip changelog] Format all docs and config files

* [skip changelog] Update contributing documentation with formatting instructions

* [skip changelog] Fix some Prettier configuration issues

* [skip changelog] Format all config files

* [skip changelog] Fix documentation indentation issue

* [skip changelog] Removed files from .prettierignore

* [skip changelog] Update docs/package_index_json-specification.md
Co-authored-by: per1234 <accounts@perglass.com>

* [skip changelog] Format PR and issues templates

* [skip changelog] Format files after rebase

* [skip changelog] Update .prettierrc and reformat everything
Co-authored-by: per1234 <accounts@perglass.com>

* Add Description field to lib list output

* [skip changelog] Fix lib list output

Output columns are now smaller, sentence is cut if too long and renamed
Sentence column to Description.

* [skip changelog] Fixed lib list output on Windows

[skip changelog] Add link to library dependency resolution process docs from library specification (#842)

Many of the things documented in the library specification are used as determining factors in library dependency resolution. An understanding of how the components of a library influence dependency resolution priorities can be very helpful to a library developer.

Previously, only the serial.port property was documented. However, serial.port.file is in widespread use (e.g., Arduino SAMD Boards).

* Make install script's check for conflicting $PATH installation more reliable

Previously, the comparison between the install script's target path and the path of an existing installation in $PATH could easily give a false positive, producing a spurious "An existing arduino-cli was found at..." error. The solution is to fully resolve the paths before comparing them.

* Don't fail installation script when other installation in $PATH is detected

Previously, when a different installation of Arduino CLI was detected in $PATH by the installation script, the error message "Failed to install arduino-cli" would be printed and the script would have exit status 1.

It is wise that the script warns of this situation ("An existing arduino-cli was found at..."), but the "Failed to install arduino-cli" error message was misleading, since Arduino CLI was indeed installed. It is also incorrect to have an error exit status in this situation, since the user may intend to have multiple installations and provide the full path when using the new installation.

* [skip changelog] Added Python linting and formatting

Python linting is done using flake8 and formatting with black.
A linting workflow will run any time a Python file is modified, a format
workflow instead can be triggered by commenting in a PR.
Taskfile has been updated with lint and format tasks.

* [skip changelog] Fixed all Python linting issues

* [skip changelog] Fix Python linting and removed format workflow

This workaround must be here until viper can UnSet properties:
https://github.com/spf13/viper/pull/519

Arduino IDE and Arduino Web Editor use the term "sketchbook", while Arduino CLI and Arduino Pro IDE use the term "user directory". In order for the documentation to be friendly to all users of Arduino's development software, both terms must be used in the documentation.

[skip changelog] Add links to additional information in the examples section of the library specification (#804)

* Move examples style guide link to examples section of the library specification

* Add sketch specification link to examples section of the library specification

[skip changelog] Use consistent indentation style in example snippets of package_index.json specification (#815)

* Use consistent index size for snippets in package_index.json specification

The predominant index size in the example snippets (as well as in Arduino's official package_index.json file) is two spaces. However, at some places in the example snippets indents of three or four spaces were used.

* Use true indentation level for package definition example snippet

All other example snippets in the documentation use the indentation level they will have in the full document, so for consistency the package definition snippet should do the same.

The library and platform specifications apply to all libraries and platforms, including official ones.

The formula should not be updated on pre-releases.