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.
Previously, a full cleanup of the work directory (and thus a full
rebuild) was done on the first build after:
- startup, or
- a change in the board or board suboption.
This did not cooperate nicely with commandline compilation using
--verify. Using the build.path option a persistent build path could be
used, but the actual files in that path would never be reused.
Now, each build saves the preferences used for building in a file
"buildprefs.txt" inside the build directory. Subsequent builds will read
this file to see if any build options changed and re-use the existing
files if the build options are identical.
Because the main .cpp file is not handled by Compiler::build, but by
Sketch::preprocess, it is still always regenerated, even if the Sketch
itself didn't change. This could be fixed later, though it is probably
not a problem.
When writing buildprefs.txt, only the build preferences starting with
"build.", "compiler." or "recipes." are used. These should be enough to
ensure files are always rebuilt when needed (probably also sometimes
when not needed, when change build.verbose for example). Using all build
preferences would cause the files to be rebuild too often, and because
of last.ide.xxx.daterun, they would still rebuild on _every_
invocation... This approach is perhaps not ideal, but improving it would
require putting more structure in the preferences instead of piling them
all together into the build preferences.
Because of this new mechanism, the old
buildSettingsChanged()/deleteFilesOnNextBuild could be removed.
Instead of defining in the preprocess method and returning, just define
it in the build method. This makes sure the name is available before
preprocessing, which is important for the upcoming commits.
This commit should not change behaviour, only prepare for the next
commits.
Previously, these arguments would be passed to the compile method.
However, passing them to the constructor makes sure that the build
preferences are created sooner, so they can be used by Sketch before
calling the compile method.
This commit shouldn't change any behaviour, but prepares for the next
commits.
