Re: gEDA-user: Per-project component libraries

[John Doty <jpd@xxxxxxxxxxxxx>]

On Jun 27, 2007, at 3:44 AM, Peter TB Brett wrote:

> On Tuesday 26 June 2007 00:10:36 John Doty wrote:
>
> (By the way, I do subscribe to geda-user, I just don't post here  
> very often!)
>
> Warning: really long e-mail ahead:
>
>> 1. When I make a change in a symbol, I most often want that change to
>> propagate to *all* instances of that symbol in a project. A
>> collection of project symbols makes this easy: Hs takes me into the
>> symbol, where I can make any change I want.
>
> However, currently when you save the symbol the changes *do not*  
> automatically
> propagate to all the currently open schematics.
>
>> 2. Once I start on a project, I want my symbols under the project's
>> revision control, not gEDA's, so that nobody can break my project by
>> "fixing" a symbol.
>>
>> It seems to me that your approach could be accommodated by fixing Hs
>> so that it can go down into an embedded symbol. Embed your symbol,
>> edit it as you please. No incompatible changes required to the  
>> software.
>
> This is needed anyway for going down into library symbols which do  
> not have an
> immediate on-disk representation (e.g. symbols generated by a  
> Scheme-based
> component-library backend).
>
> However, this is not so simple as you make it sound.  Currently,  
> there are
> many places where gschem makes the assumption that a view is  
> associated with
> a file on disk.  Secondly, there are a number of issues to resolve:
>
>  - How should gschem decide which symbols in the original schematic  
> to update?
>
>  - How would updating work?
>
>  - How would you keep all of the symbols in your multiple-schematic  
> project in
>    sync?

The way my mind works, the embedded instance is a unique thing, so  
you only would update the instance you're editing. If you want a  
common symbol behind several instances, don't embed.

But perhaps Sean has a different perspective.

>
> While I agree that it would be nice to edit an embedded symbol,  
> there are
> major technical hurdles to overcome.  Embedded symbols are  
> implemented in a
> rather "brute force" fashion currently.  Only recently was I able to
> eliminate checks for "EMBEDDED" in the symbol name (except for in  
> the file IO
> code).
>
> The "Right Thing", I believe, would be for symbols to be embedded  
> _separately_
> from the symbols _instances_.  So if you have 80 resistors in your  
> schematic,
> there would be one copy of the resistor symbol in the file, and  
> when the
> system looks for a "RESISTOR" symbol it'll use the embedded version
> preferentially to the library version.
>
> Edit->Update would then automatically update _all_ instances of the  
> symbol,
> meaning that you won't miss one.

Better to have Hu update instances of a symbol you just edited. That  
way you wouldn't need to remember the ep. I can't think of any reason  
to defer the ep.

>
> However, this requires a file-format change.

What I have in mind does not, I think

>
>> On the other hand, what *I'd* really like is explicit support for the
>> "project symbol library" concept. Specify it in gafrc. When you place
>> a symbol from the regular library, a copy should be automagically
>> placed in the project library. Symbols in the project library should
>> have priority without "duplicate symbol" warnings. The project
>> library should be first in the component dialog's list.
>
> This is not likely to happen before the 1.3 unstable series,  
> despite my
> extensive changes planned for 1.1.  However, before I dwell on the  
> exactly
> why, I'd like to explain what I've got up my sleeve for 1.1.
>
>  - I've already added the ability to add symbols generated by  
> Scheme commands
>    or other programs.  I'm going to create some sort of system  
> which allows
>    gschem to transparently populate its component library from
>    gedasymbols.org -- because all you'll need to publish a  
> component library
>    online will be an HTTP server.  *vague hand-waving*.
>
>  - I'm going to make the component selector tabbed; the "Libraries"  
> tab will
>    show something like the current view, and a new "Existing" tab  
> will show a
>    list of all non-embedded symbols used in schematics which are  
> currently
>    open.  (If I can fix the component selector dialog, perhaps I  
> can refine it
>    to the current schematic only, and iff the file-format bump  
> happens, I can
>    include the current schematic's embedded symbols).  The  
> "Existing" tab will
>    be the default unless there are no symbols yet in use.
>
>  - I'm going to add symbol categorisation, so there is more fine- 
> grained
>    control over symbol selection than just which component library  
> they're
>    from.  However, at least initially all symbols in a directory-based
>    component library will have to be in the same category; only  
> command- and
>    Scheme-based libraries will be able to take full advantage of  
> the system
>    until I devise some sort of library index file.  You'll be able  
> to switch
>    between viewing by category and viewing by library.

Sounds like chaos to me. Endless arguments over categories.

>
> So why won't per-project component libraries happen soon?   
> Basically, gEDA has
> no _concept_ of a project.

What I have in mind is simpler, I think. More like a "stockroom" than  
a "project". Multiple projects might use the same stockroom. But the  
stockroom for a laboratory instrument designed from what Digi-Key  
stocks is different from the stockroom for a spaceflight instrument  
designed from a PPL. Both are different from an ASIC. However,  
several "projects" might share a common "stockroom".

To me, a "project" is just a set of directories. That way I can make  
tarballs, use revision control systems, makefiles, etc. without gEDA  
needing to know how to manage that kind of thing. Orthogonal,  
factored design is good.

>   There is no distinction made between
> configuration variables set by the system rc files, the personal rc  
> files, or
> the project rc files.  All configuration variables are stored in  
> one of two
> places: static variables in libgeda, or as members of the singleton  
> TOPLEVEL
> structure.  This includes the list of current libraries.
>
> As an example of this (works in any version of gschem):
>
>  1. Create two directories, a/ & b/.
>
>  2. Create a blank schematic "test.sch" in each.
>
>  3. Create a "gafrc" file in b/ containing the expression
>     "(reset-component-library)".
>
>  4. Run gschem.  Open a/test.sch.  Verify that component libraries are
>     available as usual.
>
>  5. Load b/test.sch.  Observe that for _both_ schematics the component
>     library is now empty.
>
> In fact, as an example of extreme bugginess, just _previewing_ b/ 
> test.sch
> causes the component library to be reset!

I know. But I've only tripped over this once in five years. Not a  
biggie to me.

>   _All_ configuration variables are
> affected by this, and there needs to be extensive changes made to  
> the gEDA
> configuration mechanism in order to make per-project, per-user and  
> default
> system settings have contextual separation.
>
> There are some other ancillary problems as well, but that's the  
> major one.[1]
>
> For the time being (and for the foreseeable near future) the best  
> bet is to
> have a component directory specific to the project and to make it  
> the only
> library loaded by the project gafrc file.

The trouble there is that then you can't browse the gEDA libraries to  
find what you want. I do that frequently, get the name of the symbol,  
copy to the stockroom directory, change its name, place, Hs, and fix  
my way. That works, but is a bit cumbersome.

>   In addition, it's wise to load
> separate copies of gschem to edit files from different projects.
>

Indeed.

> I hope that clarifies things.
>
> Regards,
>
> Peter
>
>
> [1] Someone is bound to suggest a hack fix.  The problem with hacks  
> is that
>     with the best will in the world to fix them properly when you  
> have some
>     time, is that you never have some time.

One problem with refusing a simple pragmatic fix is that with the  
best will in the world to make an elaborate fix when you have some  
time, you never have some time. And often simpler is better anyway.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user