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).
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.
Previously, any files that were specified on the commandline but could
not be opened were silently ignored. Only if --verify and --upload was
specified and _all_ files failed to open, a generic error message was
shown. Additionally, if multiple files were specified with --verify or
--upload, only the first would be acted on (the others would be openened
and shown in the GUI, but not actually verified or uploaded).
Now, whenever a file fails to open, an error message is shown (fatal
with --verify or --upload, non-fatal otherwise).
Furthermore, with --verify or --upload an error is shown when there is
not exactly one file on the commandline.
Finally, instead of keeping an "opened" variable, the code now just
checks the size of "editors" to see if a blank sketch should be opened.
Instead of opening up files during argument processing, the filenames
are now stored in a list and opened only after all commandline arguments
have been processed.
This commit in itself shouldn't change any behaviour, but it prepares
for improved error reporting in the next commits.
Previously, this would error out with an index out of bounds exception.
Now, an IOException is thrown, which is properly handled further up the
call chain.
Previously, strings containing the board id, or a joined version of the
package, platform and board id were passed around. Since comparing
objects is easier than strings and since parsing strings can be fragile,
it's better to just pass the TargetBoard objects.
There is one case where string parsing is still required: when parsing
the --board commandline option. However, the parsing is now done in the
right place, when handling the commandline, instead of in a generic
selectBoard method.
Since the custom suboptions are only visible when their associated board
is the currently selected one, there is no point in re-setting the
current board when a suboption is selected.
The current code forbids any files it does not know about, but this is
bad because:
- It breaks forward compatibility if we later add more files or
directories to the library format.
- It breaks for people who want to have some extra stuff in their
library (say, .gitignore or a README file). We can't keep a list of
"allowed" stuff, since there will always be stuff missing.
This commit removes that code and just allows all files again.
Added an "insideString" flag in scrubComments to avoid failing with strings like "Hello */*"
Added a handful of tests taking code from various issues in order to better avoid future regressions
Closes#1687
Fix the line number font rendering problem on the Mac.
Now, the TextAreaLineNumbers class extends the TextAreaPainter and just
overloads the paintLine method to make it render the line number instead
of rendering the whole line. Other than that, the superclass' drawing
code is used.
So: the same drawing code that renders the source code text in the
editor is now also being used to render the line numbers.
Matthijs Kooijman
Cristian Maglie
Fulvio Ieva
Federico Fissore
David A. Mellis
Erwin Ried
Georg von Zengen
h2g2guy
PaulStoffregen
Cristian Maglie
Jimmy Hedman
Matt Robinson
Kristian Lauszus
Cayci