Boards menu list has been moved into Base class where it looks a more
appropriate place to reduce interactions between Editor class and Base
class.
Probably shared menus can be moved in a separate, specific, class.
- TargetPackage / TargetPlatform / TargetBoard are now interfaces
- Contributions installed are detected during init time
- Tools must be referenced through "path" property (automatically set
by the IDE to the contributed tool path)
When the "autoscroll" checkbox is deselected the buffer may continue
to grow up to twice of the maximum size.
This is a compromise to ensure a better user experience and, at the
same time, reduce the chance to lose data and get "holes" in the
serial stream.
See #2491
Before this patch every byte received from Serial
invokes a String allocation, not really efficient.
Moreover a InputStreamReader is chained on the serial
InputStream to correctly convert bytes into UTF-8
characters.
Also removed unused ColorSelector and CreateFont to reduce wrappers
size to the minimum.
This commit is preparatory for dropping dependency on processing-core.
Created a class PreferencesData to manage all parameters except the ones for the GUI.
Removed GUI parameters management from ParametersMap.
Created ParametersHelper class to help with GUI parameters management.
Used ParametersHelper in Themes.
Create a class SketchData to store all relevant data for a sketch
(trying to keep GUI stuff out of the way).
Moved preprocessing code from Sketch to Compiler.
Nobody was using it anymore, except for checking against specific
extensions, which is easily done against the filename itself. This
prepares for some simplification of Sketch.load next.
Previously, the useRecursion and srcFolders were filled on library
creation, based on the existence of the src folder. Now, a layout
variable is set, and the useRecursion() and getSrcFolder() methods
change their return value based on the layout in use.
Before, core.a would be rebuilt on every build, even when none of the
core .o files changed. Now, the timestamps are checked against the
timestamp on core.a first, skipping the build if nothing changed.
Because this uses the current list of .o files, there is a corner case
when a source file is deleted, but no other source file is modified. In
that case, core.a is not rebuilt, even though it should be. However,
this is such a narrow and unrealistic case, that it should pose a real
problem.
This fixes part of #1991
This prevents a half-finished core.a file from lingering around.
Currently, this should not make a difference since core.a is rebuilt
every time, but this prepares for skipping this build step if possible.
Before, the ar command was just ran for all .o files that should end up
in core.a, which should replace any old code in core.a. However, it
seems that in the unlikely event that functions or entire source files
are deleted, they might linger in the core.a file.
Previously, the MessageSiphon class would read characters from an
InputStream and then push them to the passed MessageConsumer one line at
a time.
Now, you can specify a line timeout. Normally, messages are still
processed line by line, but if no line ending is received within the
specified timeout (counting from the first character in the line), then
the incomplete line is passed on as a message, without waiting for the
line ending.
This feature is used for the uploader command output. In particular,
this allows the avrdude progress bar to be shown in the IDE as expected,
character by character (previously, the entire progress bar would be
buffered, making it show up completely at the end of the upload).
In the preferences dialog, the name of the preferences file is shown for
advanced editing. If the filename is clicked, the folder containing the
file is opened. However, this always used Base.getSettingsFolder, which
is the folder where the settings file _normally_ resides. But when the
--preferences-file option is used, the actual preferences file might be
somewhere else.
This commit makes sure to always open up the parent directory of the
actual preferences file in use, instead of always the default one.
When no build.path preference is present, a temporary directory is
automatically created (and deleted). When a build.path was specified,
but the directory does not exist, the IDE would show an error and fail
to build, which is unexpected and not so friendly.
This commit makes sure that the build directory is automatically
created.
Before, these were only shown in the GUI, which makes a failing
commandline build a bit puzzling. As a side effect, the error is now
shown in the log area in addition to the status line above the log
area, but that should be ok.
In a lot of places, (potentially) relative paths were passed to File
without any processing, making them be resolved without taking into
account --curdir. By passing them through Base.absoluteFile instead,
these paths are resolved relative to the working directory before
starting arduino (at least on Linux, which is currently the only
platform supporting --curdir).
This applies --curdir to the --preferences-file option and the
build.path, settings.path, sketchbook.path preferences.
For example, this now works as expected:
arduino --pref build.path=build_dir --verify Blink.ino
When a sketch looks like this:
Blink/
Blink.ino
Foo.ino
The idea is that opening Foo.ino should open up the sketch. However,
before this would show an error stating "The file Foo.ino needs to be
inside a sketch folder named Foo" instead.
This turned out to be due to a typo, which seems to have been present
for a long time. Note that when the main sketch file was a .pde file,
everything already worked as expected.
On Windows, files are canonicalized to prevent issues with legacy 8.3
filenames. However, this canonicalization includes making the path
absolute and this happened before applying --curdir to the path, making
the latter a noop.
By reversing the operations, this should allow both of them to do their
work.
This method takes filenames as specified on the commandline and turns
them into the right File object, taking into account the current
directory passed through --curdir by the wrapper script.
Previously, the argument to --preferences-file would be interpreted as a
filename, but then also checked as an option as well (in the next loop
iteration). This didn't really matter in practice (unless you would be
using a file called "--preferences-file"), but better skip the argument
anyway.
Parsing commandline arguments inside Preferences isn't very elegant,
this is better suited for the main function. Also, this change prepares
for taking --curdir into account for --preferences-file as well.
This option causes the IDE to process its commandline arguments and then
quit. This allows setting preferences uses --pref, without having to
also load the GUI or compile a sketch.
Previously, --verbose would be processed after the preferences were
saved, which should usually mean that it should never influence the
saved preferences. However, if for whatever reason Preferences.save()
would be called later, the verbosity preferences would still be messed
up.
Since we now have a Preferences.setDoSave() method, we can make sure
that these verbosity preferences (and any other preferences that are
changed after the build started) are never saved.
Preferences.init would write out the default preferences when no
preference file previously existed. This would cause a default
preferences file to be written even when --no-save-prefs was passed, due
to the ordering of things.
However, since the Base constructor now already calls
Preferences.save(), there is no need for Preferences.init to also do
this. Since Base calls this after parsing the commandline, the
--no-save-prefs option is now also properly respected.
This allows setting preferences for the current run only, without
remembering them for the next run. This is especially useful when
combined with --verify or --upload.
Before, the preferences were saved as a side effect of loading files in
the Editor, but it seems better to explicitely save them as well (this
should prevent problems later on, if the Editor class is no longer used
in --verify or --upload mode).
Since the handling of these options defaults to non-verbose (instead of
the current preference), they make no sense when starting the IDE
normally. Previously, these options would just be ignored in this case,
now an error is shown.
Previously, the --board and --port arguments were stored in a variable
first and only processed later. Now, the arguments are processed right
away.
This does mean that the arguments are processed when the GUI is not yet
initialized, which caused problems with calling onBoardOrPortChange and
friends from selectBoard. However, since the GUI is not initialized,
there is no real reason to call them either - if we just set the
preferences to the right values, the GUI will be initialized correctly
later. For this reason, selectBoard no longer calls the GUI update
methods. Instead, those are called from the GUI code when the board is
changed through the menu instead (e.g., after calling selectBoard).
This commit slightly changes behaviour. Previously, --board and --port
only worked in combination with --verify and --upload, but were ignored
when just starting the IDE. Now, these are processed regardless of the
other options present.
Additionally, this commit causes all changed preferences to be saved.
Previously, only changes with --pref were saved, --board and --port
options were only active for the current run. This was caused because
the saving of the preferences happened as a side effect of loading the
file in the Editor, but only the --pref option was processed at that
time.
Note that the --verbose options are still only active for the current
run and are only valid combined with --verify or --upload (since they
default to non-verbose instead of the current preference).
This method takes care of setting the serial.port preference to the
given value, as well as deriving the serial.port.file preference. This
should prevent duplicate code in the future.
Note that a second copy of this code lives in SerialUploader, but that
doesn't write to the global Preferences but a local prefs map. Since the
global Preferences are currently static, there is no way to share code
between these two copies.
This uses a switch on the action value, which makes it more clear what
code runs when. No actual behaviour is changed, most of the changes in
this commit are indentation changes.
Previously, the code showed an error when the given action was not
upload or verify. This is now reversed: the GUI is shown when the action
is "GUI" (which is the default when no action specified). Since the
action enum only contains these three values, there is no change in
behaviour, but this makes it easier to add new actions later.
Previously, two separate booleans (doUpload and doVerify) were used.
However, since it always makes sense to specify only one of them, it
makes more sense to keep a single action enum variable, which slightly
simplifies the code (especially when more actions are added later).
Additionally, an error is now shown when both --verify and --upload are
specified on the commandline.
If a variant supplied source files, these would be included in core.a
before. However, object files from core.a would only actually be
included in the build if they supplied a symbol for a strong reference
that was still missing.
In practice, this meant that a variant source file that only defines
interrupt handlers, or only defines strong versions of functions that
already had weak versions available, was not included.
By moving the variant .o files out of core.a and including them in the
build directly, this problem is solved.
Furthermore, the compilation of variant files is moved to after the
generation of core.a, to make it clearer in the code and verbose output
what is now happening.
When a core directory without boards.txt file was encountered, the IDE
would show:
Could not find boards.txt in /path/to/core/boards.txt. Is it pre-1.5?
Which appears confusing: Is it looking inside a directory called
boards.txt? Now this is improved to:
Could not find boards.txt in /path/to/core/. Is it pre-1.5?
which makes a lot more sense.
When a path contains spaces (or other special characters, probably), gcc
escapes them with a \ in the generated .d files. This previously caused
problems when parsing these files, causing recompiles to happen even
when not needed.
This applies a rather simple approach to unescaping these strings, which
seems to be sufficient because the file format of the .d files is so
predictable (e.g., we don't actually split on colons or spaces when
parsing it).
Previously, preferences suffixed with .macos were treated specially,
but the default preferences.txt used .macosx.
I couldn't find when or how this was broken exactly - it seems
Processing used .macosx but this code was reimplemented for Arduino in
commit 33f5c53 (Implemented OS specific preferences) using .macos.
The effects of this have not been tested on OSX, but this might fix some
problems caused by wrong defaults on OSX.
In preferences files, platform-specific versions can be indicated by a
.linux, .windows or .macos suffix on the key name. Previously, these
keys were loaded as normal and then afterwards, all keys were scanned
after loading them and any platform-specific versions replaced the
regular ones.
However, this means that these platform-specific versions get an
unexpected form of priority. Normally, when a single key is set twice,
the latter overrides the first. However, the platform-specific values
could override the regular versions, even when the regular version
occurs later in the file.
This problem was particularly confusing when using the new
platform.local.txt: a regular preference in platform.local.txt did not
override a platform-specific preference in platform.txt.
This commit changes behaviour to process these suffixes directly as they
are read from the preference files. If a suffix for the current platform
is found, the line is processed as if the suffix was not present. If a
suffix for another platform is found, the line is ignored altogether.
This can slightly change the way preferences files are parsed, but as
long as platform-specific preferences are defined after the
corresponding regular preferences, the behaviour should be the same.
Previously, this relied on an (ugly, avr-specific) magic default for the
compiler.path variable, set by the IDE. This allowed the IDE to fall
back to a system-wide toolchain when no bundled toolchain was found (by
making compiler.path empty).
However,
- this only worked for avr, not sam,
- this worked only for gcc, a system-wide avrdude would break on the
avrdude.conf path in platform.txt, and
This would mean that automatic system-wide fallback didn't work in all
situations, so you'd still have to modify platform.txt (or create
platform.local.txt). Since doing that explictly is the most reliable
way, this commit removes the partial-working ability to do this
automatically.
Note that the code to automatically set compiler.path is still kept
around, in case third-party hardware still relies on this. At some
point, this code should be removed, but for now it just shows a warning
message.
This helps advanced users that want to change options (e.g. to use a
different toolchain or enable warnings), without having to change
platform.txt (which could make git report changed files all the time).
Federico Fissore
Cristian Maglie
Ivo van de Grift
Geronimo Bareiro
PaulStoffregen
swordmaster2k
wayoda
Claudio Indellicati
Matthijs Kooijman
Fulvio Ieva
David A. Mellis
Erwin Ried