kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>> 
>>> Wayne Stambaugh wrote:
>>> 
>>>> Mateusz wrote:
>>>> 
>>>> 
>>>>> Could you tell me how this "tags" will be\are implemented in .lib files? Do you need a special tool to add key words, or can it be done via library editor?
>>>>> 
>>>>> 
>>>> When the component library editor saves a component library, two files
>>>> are created. The .lib file contains the information about how to draw
>>>> the components, default field values, aliases, etc. The .dcm file
>>>> contains documentation for each component and component aliases for a
>>>> library.
>>>> 
>>> I thought I remembered a discussion about removing the dcm files, or 
>>> putting that info into the other file.
>>>
>>>
>>> Am I imagining this discussion? I honestly cannot remember for sure, 
>>> but I thought Jean-Pierre was OK with removing the dcm files. I think 
>>> long term having to marry two files together may eventually get in our 
>>> way and be cumbersome.
>>> 
>> Dick,
>>
>> These are separate discussions. I discussed merging the two files as
>> part of the ongoing improvements to the component library object. I
>> have been slowly adding the base code required to accomplish this in an
>> unobtrusive manor as possible. When I discussed this with JP, there was
>> no talk about the library improvements currently being discussed. I am
>> perfectly fine with not merging them if the proposed library clean ups
>> will make the .lib file too unwieldy. Currently the .dcm files really
>> don't have much information in them. If the folks working on the
>> library improvements add a lot of additional documentation to the .dcm
>> files then your concerns may be valid. I was thinking primarily from a
>> developer point of view of have to maintain a separate parser for the
>> .dcm files. If we choose not to merge them, I will update the file
>> format documentation.
>>
>> Wayne
>>
>> 
> 
> There is no hurry. I just think that once we have all the concerns on 
> the table, that in the final solution having two files per symbol is 
> pretty silly. Eventually an external conversion program could be 
> written, so only one format need be supported within Kicad itself, (the 
> newest format at that time).

Dick,

I was planning on using the library file version number to determine if
merging the lib and dcm files was required. Once the files are merged
and written to the new format, the user or Eeschema is free to delete
the dcm file.

> I simply don't think having two files per symbol will do us any good at 
> all long term, not when you start talking about web-based repositories 
> and what not.
> 
> 
> But a hypothetical migration to a new file format should be done as part 
> of a comprehensive deliberation which would address as many current 
> shortcomings as are evident at that time, so the conversion program only 
> has to be written once, and users only would have to convert everything 
> once.
> 
> 
> I like extensible, self documenting text file formats, but when 
> comparing say specctra DSN against XML, I think the DSN format is *far 
> more* human readable. I know and love the parser that we have for that 
> DSN format, and know that all a person needs to do to re-use that parser 
> in another domain is simply supply it with a new keyword table and 
> matching enums. (Ouch, this is not the search "keywords" we were 
> talking about earlier.) That parser's advantages are that it supports 
> C++ exceptions, and accurately reports input file line numbers, and can 
> verify grammar by using recursive descent.

I am more than happy to discuss an improved library file formats to
support future requirements. I haven't taken a close look at the DSN
file format. When I get a chance I'll take a look at your spectra code
and the resulting file format so I can see how it would fit into
handling component libraries.

Wayne

> 
> I remain fairly impressed with the specctra DSN file format (in a 
> general sense, not speaking about the specific keyword grammar that we 
> expect in it now).
> 
> 
> Dick