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).
JSSC, on unix based systems like linux and MacOSX, when listing serial ports
tries to open each port to ensure its existence. While this check works well for
linux ports /dev/ttyS0..31, it leads to unexpected behaviuors on MacOSX in
particular with USB-CDC virtual serial ports.
This patch disable the check and keep it enabled only for linux ttySxx ports.
This adds also tty.* and cu.* to the list of available serial ports on MacOSX.
