Previously, the built-in examples assembly step of the build system set the
`final_folder` parameter of the `unzip` target to the true final
installation location of the examples.
The behavior of the `unzip` target is to only unzip the archive if
`final_folder` doesn't exist. Because that folder will exist any time a
previous build has been done and `ant clean` was not run, the archive will
not be unzipped. This causes the build to fail after an update to the
built-in examples version when it attempts to copy the examples from the
version-dependent extraction staging folder to the final location.
The fix is to set the `final_folder` parameter to the version-dependent
staging folder location, which will cause the extraction to happen every
time the examples version is updated, but to be skipped when there was no
update.
A dedicated repository for the examples will make it easier for them to be built in to arbitrary development tools. It will make it easier to use them for compilation testing of boards platforms. It provides a dedicated location for issue reports and pull requests that are specific to the examples. It continues the work done by moving the AVR and SAM boards platforms and built-in libraries towards making the arduino/Arduino repository solely a place to host the GUI code of the Arduino IDE.
Some platforms may not define directly 'build.core' because it may be defined
through a custom menu.
For example, the arduboy platform has in the boards.txt:
[...]
menu.core=Core
[...]
# core #
arduboy-homemade.menu.core.arduboy-core=Arduboy optimized core
arduboy-homemade.menu.core.arduboy-core.build.core=arduboy
arduboy-homemade.menu.core.arduino-core=Standard Arduino core
arduboy-homemade.menu.core.arduino-core.build.core=arduino:arduino
[...]
the build.core is determined only after applying the submenu options.
Previously changing "Category" would filter libraries by the selected
category but without applying the "Type" previously selected.
For instance selecting Type="Installed" and Category="Communication"
will display *all* the libraries belonging to "communication" instead of
the installed only.
This commit fix this behavior.
The filters content is unlikely to change, so just prevent it from live
updating it because it has some side effects:
- it's slow
- it changes the selection back to the default and it's very tricky to
make it re-select the previous selection.
Fixes#10439
Previously rescanLibraries() was automatically called internally in
setLibrariesFolder(). This lead to double calls to rescanLibraries()
when setLibrariesFolder() was used in combination with an explicit
call to rescanLibraries().
This commit adds a new method setLibrariesFoldersAndRescan(..) and
removes the internal call to rescanLibraries() from setLibrariesFolder().
The existing setLibrariesFolder()+rescanLibraries() combos have been
replaced with setLibrariesFoldersAndRescan().
Fix#10228
Previously, any CR without NL was treated just like a NL. For tools that
used single CRs to update a progress bar (such as dfu-util), this would
end up printing the subsequent versions of the progress bar below each
other, instead of updating a single line as intended. Additionally,
since ConsoleOutputStream only scrolled the view on \n, these updates
would end up outside of the main view, making the upload progress quite
unclear.
This commit makes EditorConsole support lone CRs by resetting the insert
position to the start of the current line, so subsequent writes
overwrite existing content. If subsequent lines are shorter than an
earlier line, only part of the earlier line will be overwritten (this
mimics what terminal emulators do).
Previously, the redirection would be triggered in the EditorConsole
constructor. However, this was problematic for unittests, which do not
need this redirection.
Since the redirection really is not useful intul there is a current
EditorConsole anyway, it can just be delayed a bit until
setCurrentEditorConsole is called.
This prevents the Arduino instance in tests from checking for updates. I
have not seen any problems resulting from this, but disabling network
requests is generally a good idea in tests (to prevent external factors
from influencing the test results).
In addition to update checks, there is also the CloudBoardResolver that
could do network requests, but there does not seem to be a preference
for disabling that.
This would match the "Close" dialog, by looking for any JDialog on
screen. However, in some cases, there could be a second dialog (I have
seen a "Install this package to use your xxx board" popup because I
happened to have an Arduino Zero connected, presumably an "Updates are
available" popup could cause this as well).
By matching not just the type of the dialog, but also the title, only
one dialog is matched and the testcase runs more reliably.
The tests would initialize Base, PreferencesData with default settings
and/or run the arduino executable, without specifying any settings to
use. In practice, this would read settings from e.g. `~/.arduino15`,
load libraries from the user's sketchbook, etc.
This is not a good idea, since this can be influence the test. For
example, the presence of invalid libraries would cause extra output to
be generated, which breaks the `--version` test. Or having the "Use
external editor" setting set would break tests that try to edit a
sketch.
This commit fixes this. The core of this commit is in
`AbstractWithPreferencesTest`, which sets up a clean settings dir (to
replace `~/.arduino15`) with a sketchbook and `preferences.txt` file
inside before every test (and removes it again after the test.
For some tests, this is enough, but some tests create an instance of
`Base`, which again initializes everything, including preferences, from
the default location. To prevent that, `--preferences-file` is passed to
the `Base` constructor, loading the previously set up preferences. This
is handled by the new `AbstractWithPreferencesTest.createBase()` method.
Furthermore, CommandLineTest calls the actual Arduino executable, which
has the same problem. This is fixed by passing the same
`--preferences-file` option on the commandline (generated by
`AbstractWithPreferencesTest.getBaseArgs()`).
This should prevent all tests from reading the the default settings
files, fixing some tests on my system and even speeding up the tests
somewhat (due less libraries and cores to load, probably).
Normally, init is only called once during startup, so this does not add
anything. However, when running the testsuite, PreferencesData could be
initialized multiple times in a single test run. To prevent preferences
from a previous test from interfering with subsequent tests, always
start with a clean slate when calling init.
Previously, this used the DeleteFilesOnShutdown class and a shutdown
hook, which would delete the files only after shutdown. However, the
shutdown handler would be re-added for every testcase, potentially
leading to a lot of threads trying to delete the same files.
This uses an alternative: Just keep a list of files to delete inside the
testcase and use an @After handler to delete the files directly after
each usecase.
Both classes contained some duplicate code, so unify that by making one
a subclass of the other. This also prepares for further additions that
should be inherited by both.
In one test, `--get-pref` is passed on the commandline to prevent
starting the full GUI. When ran without arguments, `--get-pref` causes
*all* preferences to be printed. Using `--version` achieves the same (no
GUI is started) with just a single line of output.
This abstracts some the common code (running Arduino, copying
output, waiting for completion, checking result) from all testcases into
a single method. This simplifies each testcase, but also prepares for
adding more common arguments to all runs in a subsequent commit.
Previously, it was ran before each test, but just running it once before
all tests is sufficient. So switch from @Before to @BeforeClass and make
the its result variable static.
