kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #36045
Re: Another problem with the generic (XML) netlist exporter
Le 03/06/2018 à 19:08, Jeff Young a écrit :
> That when folks produce a BOM including descriptions all aliased parts have the wrong descriptions.
Are you sure? Have you tested it?
I just tested a alias in a netlist:
Here is the description in (components ... ) section:
(comp (ref JP101)
(value ALIAS_OF_JUMPER)
(datasheet "doc of alias_of_jumper")
(libsource (lib pic_programmer_schlib) (part ALIAS_OF_JUMPER))
(sheetpath (names /) (tstamps /))
(tstamp 5B14DAFF))
the description looks good to me and is the description of the alias I entered in library.
>
> (I don’t know if anyone has produced 3rd-party tools to do footprint selection, but the footprint filters would also be wrong if they did.)
Aliases share the footprint filters.
>
>> On 3 Jun 2018, at 17:46, jp charras <jp.charras@xxxxxxxxxx> wrote:
>>
>> Le 03/06/2018 à 18:10, Jeff Young a écrit :
>>> We currently export library components the same way we store them (ie: just the root, with a list of aliases).
>>>
>>> We do not output the alias descriptions, documentation links or footprint filters. The missing documentation links are OK since these are copied to the datasheet fields of the individual components; the missing descriptions and footprint filters are a problem for BOM generators.
>>>
>>> Since aliases are mainly a way to ease authoring, I propose that we write out a flattened version of the library components — that is we write out a component for each alias. (We can still list the aliases in the root component for 3rd-party readers that are looking for it.)
>>>
>>> Thoughts?
>>
>> What is the *actual* problem to solve?
>>
>> --
>> Jean-Pierre CHARRAS
--
Jean-Pierre CHARRAS
Follow ups
References