Mail Archives: geda-help/2012/10/16/15:18:47
On Oct 16, 2012, at 2:11 AM, Karl Hammar wrote:
> John Doty:
>> On Oct 14, 2012, at 2:27 PM, Benjamin Bergman wrote:
>>> On Oct 13, 2012 12:50 PM, "Karl Hammar" <karl AT aspodata DOT se> wrote:
>>>> Well you could possible use the md5sum of the sym file, what about:
>>>> $ md5sum git/openhw/share/gschem/diode.sym
>>>> cc2da042b5ea5afd65f4153bfff79b92 git/openhw/share/gschem/diode.sym
>>>> And in the .sch file, this file is referenced by:
>>>> C 18600 19900 1 0 0 diode.sym md5=cc2da042b5ea5afd65f4153bfff79b92
>>> I think this is the way to go. This is essentially how all content
>>> is tracked and referenced in git and adds a layer of corruption
>>> detection, while costing very little in terms of resources or
>>> infrastructure.
>>
>> Shudder. That assumes that symbols rarely change.
>
> That is a false assumptions, and I have seen symbols dissapear from
> the cvs also. But that doesn't hinder you to have a directory
> structure like
>
> ver1/diode.sym
> ver2/diode.sym
> ver3/diode.sym
>
> and regardless of the order which thoose appear in the lib-browser,
> a md5-tag could find the right diode.sym for you.
Well, when I use gEDA, I do not have promiscuous settings for library search. Indeed, for big projects, I've become fond of the (reset-component-library) function. This allows me to have complete control of the symbols a project uses. The browser then only sees symbols in the project's controlled set. For broader search, I'll use a command line like "locate .sym | grep -i diode". That finds just about every diode symbol on the entire machine: standard gEDA, gedasymbols, and every gEDA project I've worked on (over 10 years!). If I find what I need, I can copy to one of the project's symbol directories.
You can see the beginnings of an elaborate project of this kind at github.com/noqsi/VideoASIC. Not too much of the gEDA part is there yet, but it'll be coming soon now that the background math is done.
> And why not allow
> a cvs-tag/git-commit-id to extract that old sym file from the
> version handler?
>
>> But a sensible way to use gEDA is to have project-local symbols
>> that change as packaging or other part selection attributes change.
>
> That is what works today, but that shouldn't hinder us to try out
> other ideas.
The problem with your idea is that it puts restrictions on the tools.
>
> ///
>
> It is nice to include the cvs sym's in the library browser, at
> least to find what's out there. Currently one cannot use the second
> or third of a duplicate sym (unless you copy or embed it); I think
> it would be nice to solve that little problem.
>
> ///
>
> Having a md5-thing as exemplified above could alert us when we have
> forgotten to update our sch's when we made changes to the project
> local sym's.
Well, the way I use the toolkit I don't normally have to worry about that. But a fairly common case is to change something like the default resistor footprint. That's an advantage of project-specific symbols now. I'll have a "resistor.sym" in the project. For the "breadboard model" that'll have a reasonably big footprint, maybe 0805. Then, when the customer's happy with the design, I can change the package to whatever the area constraints for the production board demand. To do this, all I need to do is change one symbol. Nothing else needs updating. But your way I might have to update hundreds of symbols across dozens of schematics.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -