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.
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.
Cristian Maglie
Matthijs Kooijman
Federico Fissore
Fulvio Ieva