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).
Fixes#1203.
The original patch was introduced to workaround a problem with ArduinoISP reported
in #995. After some debugging it seems caused by a glitch in RXTX library,
more discussion here: https://github.com/arduino/Arduino/issues/1203
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.
"runtime.hardware.path" now contains the path to the hardware folder
of the currently selected board and "runtime.platform.path" the path
to the specific platform.
This should fix#1176 and #1761.
Previous commits made all failures return 1, even though originally an
unknown sketch file would return 2. This restores the previous behaviour
and adds return code 3 to mean invalid options specified.
The return codes are now:
0: Success
1: Build failed or upload failed
2: Sketch not found
3: Invalid commandline options
These are intended to be ran from the commandline, so showing the GUI
doesn't make so much sense.
This is not quite the perfect solution yet, because an Editor object and
all kinds of GUI objects are still created. This commit only prevents
them from being visible, which is a nice first step, but not quite
pretty yet. However, to do it properly, some code should be moved out of
the Editor class, so that's a bit more work.
Additionally, any messages shown with Base::showError and friends still
create a popup, they probably shouldn't do this either.
When System.(out|err).print was used before there was a visible
EditorConsole, the message was written to the stderr/stdout by this
instead of the EditorConsole. However, the write(data, offset, length)
version would not pass on its offset and length parameters to the
stdout/stderr stream, causing (parts of) a message to be printed
multiple times.
This commit makes sure the parameters are all properly passed to the
real stream.
For some reason the write(int) and write(byte[], int, int) methods in
PrintStream do not throw an IOException like the write(byte[]) version,
so the try block has to go.
