Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config file to accept command options #1229

Closed
RalphCorderoy opened this issue Mar 21, 2021 · 9 comments
Closed

config file to accept command options #1229

RalphCorderoy opened this issue Mar 21, 2021 · 9 comments
Assignees
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement

Comments

@RalphCorderoy
Copy link

It's tedious writing --fqbn .... I have a arduino-cli.yaml in the current directory but it only accepts a few options. A cmd section could have have subsections for each subcommand and within those each would be a subcommand's option, e.g. cmd.compile.fqbn. This would allow per-sketch settings to be stored under Git unlike environment variables. And if a file is sourced to set the environment then forgetting to do it causes problems whereas the local arduino-cli.yaml is always present.

@ubidefeo
Copy link

@RalphCorderoy
we are addressing this need in other ways.
The CLI config file is not the correct place for this to happen.
For now you have to go through this it's maybe faster to create a "build file" you can pass parameters to and wrap the CLI.

A great example is how Sayanee Basu uses Arduino CLI with a Makefile
https://www.youtube.com/watch?v=cVod8k713_8

In the description you also find links to the demos she runs.
In the future we'll introduce easier ways of getting around this

@jockm
Copy link

jockm commented May 12, 2021

Sure, but one day you need to do something unusual and different and have to use the command line and then I have to manually enter a 143 character FQBN just do do something one off. The command line is all well and good, but I would like a settings file for build options... like other similar platforms do

@RalphCorderoy
Copy link
Author

Thanks, @ubidefeo, but I already have a Makefile with targets to build the hex, tags, prog, clean, etc., all of which can use the Makefile's $(BOARD_NAME) I've set when running arduino-cli. The problem comes, as @jockm says, when wanting to do ad hoc arduino-cli runs at the shell rather than the canned Makefile commands, perhaps because some different options want to be given.

@silvanocerza
Copy link
Contributor

There are plans to store some information in the sketch.json file to run the compile command without the need to specify some flags, nothing set in stone for now but it will come sooner or later depending on what we'll need to prioritize. Anyway we need to work on some other things before working on that.

It would greatly help if you outlined your workflow, maybe there is already a way to do what you want to do but I need more information to be sure.

On a side note the arduino-cli.yaml file is used to store global configs for the Arduino CLI only, it's not meant to store individual Sketch configurations.

@jockm
Copy link

jockm commented Nov 26, 2021

@silvanocerza If the arduino-cli.yaml can live in the sketch directory, then conceptually it isn't just global configuration. There is no practical reason it can't be used for sketch level settings. Indeed I have always assumed there was global one and the local one would override the specific settings present.

Putting sketch level settings there makes sense, without the need to add another file to the directory

@silvanocerza
Copy link
Contributor

Indeed I have always assumed there was global one and the local one would override the specific settings present.

You assumed correctly, if the arduino-cli finds a arduino-cli.yaml file in the current working directory it overrides the global one. I don't like this behaviour and would very much prefer to change it, arduino-cli.yaml must be meant to store settings about the arduino-cli and only that.
It now works like this for legacy reasons, it will probably change in the future.

Putting sketch level settings there makes sense, without the need to add another file to the directory

We have a plan to store Sketch configurations, part of that plan is outlined in the build profiles RFC.
arduino-cli.yaml as of now is not meant to store any Sketch configurations and probably never will.

@jockm
Copy link

jockm commented Nov 26, 2021

@silvanocerza

as of now is not meant to store any Sketch configurations and probably never will.

Yes that was clear from what was previously said in this issue. I was arguing that you don't need another file. I was giving feedback

@per1234
Copy link
Contributor

per1234 commented Nov 26, 2021

If the arduino-cli.yaml can live in the sketch directory

It can, but note there is no special treatment of the configuration file in that location. The configuration file is handled the same when it is in the sketch folder as when it is in any other folder.

Other parts of Arduino CLI do give special treatment to the sketch folder in that it uses the current working directory as the default sketch path argument. So it is convenient to run Arduino CLI commands from the sketch folder, and when you do that a configuration file in the sketch folder will be used. But Arduino CLI commands also might be ran from any arbitrary location, specifying the sketch path as an argument to the command.

It is possible that this loading of the configuration file from the current working directory might be problematic: #758

@per1234 per1234 added type: enhancement Proposed improvement topic: code Related to content of the project itself labels Mar 31, 2022
@umbynos
Copy link
Contributor

umbynos commented Nov 30, 2022

Hi @RalphCorderoy, we added the sketch project file which should solve your problem.
The command arduino-cli board attach -b <fqbn> <sketchpath> will produce a sketch.yaml file that will contain the fqbn to be used as default.

@umbynos umbynos closed this as completed Nov 30, 2022
@umbynos umbynos added the conclusion: resolved Issue was resolved label Nov 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

6 participants