This adds a description of commandline options, files used and some
preferences in proper Unix manpage format. It is written in asciidoc,
which can easily be converted to both a native troff manpage, or HTML
(the latter can be done by github on-demand).
This file is not installed by the ant build, but is intended for use by
Linux distributions.
The actual file was taken from the Debian package, version
1:1.0.5+dfsg2-1 and is licensed under the GPL-2+. The GenericName,
Comment and Categories fields were changed to better reflect the Arduino
program and Desktop specification.
This file is not installed by the ant build, but is intended for use by
Linux distributions.
The actual file was taken from the Debian package, version
1:1.0.5+dfsg2-1 and is licensed under the GPL-2+. It was only modified
to remove a FIXME comment that is no longer relevant.
These are Arduino icons in various formats that can be used by
redistributors in menus etc.
These icons were taken from the Debian package, version 1:1.0.5+dfsg2-1.
According to the copyright file in there, all icons are licensed under
the GPL-2+.
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.
Federico Fissore
Cristian Maglie
Matthijs Kooijman
ntruchsess
Fede85