[SCHEMATIC] BOM generation command line arguments: stored as Global or per-Project?

[fred4u]

For BOM generation, I’m using KIBOM plugin which accepts several input command line parameters.
Among others, there’s “VARIANT” field passed to KiBOM which allows me to filter the BOM output for a particular design variant.
This VARIANT is usually project-specific.
Unfortunately, current implementation seems that the BOM command line is stored as Global (Program) parameter, and not Project-based. In consequence, each time I open new project I get the last used command line parameter set (from other project). I’d prefer that this BOM filter command line was stored for individual projects.
Is there any work-around for this? Or should I post a feature request on Gitlab?

[johannespfister]

From the KiBoM GitLab Repository README.md:

BoM options are user-configurable in a per-project configuration file.

As far as i understand it: There can be a optional configuration file and there can be optional command line arguments. If there is a configurations file, it will be read and the options will replace the defaults. If a command line argument is given, it will overwrite that (again).

You can set the configuration file with --cfg, default is bom.ini. You can create a configuration file in every project with the same name (bom.ini would make the most sense) and only specify --cfg bom.ini on the command line. You can see a example configuration file here: https://github.com/SchrodingersGat/KiBoM/tree/master/test/bom.ini The option board_variant = ['someVariant','someOtherVartiant'] under the section [BOM_OPTIONS] is probably the most relevant for you (AFAIK: you can delete all the other lines excpet [BOM_OPTIONS] and board_variant = .....)

To be fair, i didn’t try that. I only looked at the code and documentation, so maybe it is completely wrong what i said, but you should try it anyway.

[fred4u]

Thank you for the info provided.
May be I was not clear enough with my attempts of explanations.
I have several projects made with KiCad. Assume these are ProjectA, ProjectB etc.
These projects have their variants, which are named differently in different projects.
For example, ProjectA have two variants: MINI and MAXI.
ProjectB have another two variants: LEFT and RIGHT.

I’m generating my BOMs with the KiBOM. In schematic editor, I do have my export parameters given as command line arguments. One of the parameters is the “–variant” param.
Then if I open ProjectA and generate BOM for the “–variant MINI” and close my ProjectA.
Next I open ProjectB and try to generate BOM, the command line stores my “–variant MINI” command line parameter (which was releavant for ProjectA and not ProjectB). I can change it to “–variant LEFT”, but then if I return to ProjectA I do have by default “–variant LEFT”.
Now if this command line was stored in the project file (one for ProjectA, other for ProjectB) it would work better for me. I’m looking for a way around this.

EDIT: Okay now I do get your hint. Instead of using command line parameters, you recommend to keep the releavant config in the project-specific “bom.ini” file, and make the command line universal using the per-project created “bom.ini”. That could be something.
Anyway, lack of proper Variant handling is probably one of my mostly missed feature. Hope time will bring something nice. I already like the clear DNP markers for V7.

[johannespfister]

Okay now I do get your hint. Instead of using command line parameters, you recommend to keep the releavant config in the project-specific “bom.ini” file, and make the command line universal using the per-project created “bom.ini”.

Yes. Very likely that was the developer(s) of KiBoM intention. It also makes it clear what export settings you use when someone has the project files (including bom.ini).

You can export multiple variants at once when you list all of them in board_variant = ['someVariant','someOtherVartiant','MINI','MAXI'], so you don’t have to change bom.ini every time you want to look at the export of a different variant.

Anyway, lack of proper Variant handling is probably one of my mostly missed feature. Hope time will bring something nice.

Variant management would be nice but there is no one clear obvious way how to implement it and no matter which way they choose, it will not be optimal. In other words implementing it properly is hard.