Use the directory of the arduino-builder binary as the default tool/library/hardware path

[lukasbestle]

The -tools, -hardware and also effectively the -libraries options are required for arduino-builder to work.

Since arduino-builder is now shipped with Arduino, wouldn't it make sense to default to the the appropriate paths in the subdirectories of the binary's directory? If the directories don't exist (for example when arduino-builder is built from source or moved somewhere else) it could still exit and ask for the options to be passed manually.

I think this would make it much easier to get started with arduino-builder.

[matthijskooijman]

Paths relative to the arduino-builder directory might be useful, but in practice these paths can exist in various places: arduino install directory, sketchbook, ~/.arduino15 directory. Adding all of these by default means duplicating some logic in arduino-builder, which might not be ideal, and adding just the arduino install directory might be confusing to users.

Still, adding some defaults paths might be a good idea, dunno.

[lukasbestle]

Well, what happens if you download Arduino? You get a directory with the arduino-builder binary inside it (and, depending on the OS, some other stuff). This directory contains the necessary tools and hardware definitions that work for most users. The users who download or customize the hardware definitions or use their own libraries should be able to add another argument when running arduino-builder, all others wouldn't need to.

After all, the users of arduino-builder are those who have more experience with the shell and want to build sketches without human intervention. And they probably use custom paths for user libraries anyway (for example on a unit testing server).

[matthijskooijman]

@lukasbestle Note that you can also still call the Arduino IDE on the commandline (e.g arduino --verify /path/to/foo.ino) to get things compiling. That does currently still require a graphical environment and shows some errors graphically, unfortuantely.

[lukasbestle]

I know, but that can't be the solution given that arduino-builder exists, does not require Java and is generally better suited for this use-case.

It's no problem for me, because I have already configured my building environment after puzzling together the required options, but I think it could be easier for others (and a bit for me, since this change would shorten my Makefile quite a bit).

[spiderkeys]

As I mentioned in #76, I also have to do the same sort of hacky, hardcoded things as @lukasbestle in order to get arduino-builder to build sketches on my headless ARM computer, as it is unable to correctly detect where things like tools (CMSIS, upload tools, etc) are. I really believe that arduino-builder should be treated as an application that can completely stand alone without needing the normal IDE installed, meaning it would be great to also have it be able to download and install cores, boards, etc. like it's IDE counterpart. I've accomplished this with some bash scripts of my own.

I'm not sure how it is trying to resolve the variables such as {runtime.tools.ctags.path} and {runtime.tools.avr-gcc.path}, but it seems like it would be prudent to set up some kind of config file for the tool to specify which directories it should be searching for these dependencies, whether it be the same directory relative to the binary or otherwise. Until that is solved, the custom SAMD21 variant that I made for our robotics platform can't be used in a standard Arduino fashion (using recipes and variables) outside of the very specific build environment I set up.

Note: The -hardware and -libraries work great, just seems to be the -tools option that gives me issues, and I assume that if it was working, it would solve these issues, though a default configuration/config file relative to the binary would be a welcome addition.

[lukasbestle]

arduino-builder is already independent from the IDE, you only need the tools and hardware definition files from the IDE download (or from the source). I don't think that builder should duplicate all the IDE features after all. It is simple and it should stay simple.
If you need to, you can prepare your hardware folder using the IDE and then copy it to your ARM box.

[spiderkeys]

I'm not saying it should implement all of the features, but being able to fetch the official hardware and library folders isn't that complex. Making it so that you have to go find and download those folders (either from the source releases or by downloading the IDE, downloading them there, and then copying them over) makes it less simple, to use, in my opinion. When it comes to trying to building sketches on ARM, there are no official packages or releases, and you have to jump through a bunch of hoops to get everything set up.

If you added both the features of being able to fetch the official hardware folders and configure the default paths that arduino-builder looks in, there would be an easy, cross-platform workflow for building arduino sketches that would look something like:

• Clone, build, and install arduino-builder
  • Part of this would need to be building/downloading platform specific tools: Ctags, CMSIS, BOSSAC, OpenOCD, avrdude
• Modify or add additional default hardware/lib paths in a config file (optional)
• arduino-builder -install {core/version } -location={optional, hardware dir path}
• Can now build sketches on any platform with no need to download the IDE or figure out where to get the correct hardware/cores/tools releases

If you are using arduino-builder as packaged with the IDE, you're already good to go, because all of your dependencies are bundled and default locations configured (for platforms that can build and use the graphical interface). There should be no conflict.

I know that ARM/headless use is a minor subset of the use cases, but it just doesn't seem like it should be hard to support an amiable workflow for this configuration. With all of the single board MPU+MCU packages popping up, it would be appreciated and I know that at least I would find it useful for continuous integration and for use on my desktop as well.

[patrickelectric]

I think that hardware, library, tools must be set with a default value..
It will be compatible with multiple computers, a better use of the tool and very intuitive..