Why don't we simply write a script, that will collect all the symbols used in a schematic file, copies it to the local directory, and we're done. Everything would remain compatible, and you had all your things in your project directory.
I think gEDA does not have a concept of a "project", but with unix tools (make, sh, etc.), we can create one. A local gafrc helps a lot too. I think that is what Unix is about. For my "project concept" implementation, please go to this page: http://levente.obudanet.hu/cgi-bin/viewvc/viewvc.cgi/pskel/ Levente Peter TB Brett <[EMAIL PROTECTED]> wrote: > [-- multipart/signed, encoding 7bit, 1 lines --] > > [-- text/plain, encoding quoted-printable, charset: iso-8859-1, 129 lines > --] > > On Friday 19 October 2007 21:32:12 Peter Clifton wrote: > >> > What library? We don't even yet have the most crucial thing: the >> > project library concept. So we all implement it in ad hoc ways, >> > because the symbols in the distributed library are usually wrong for >> > any specific purpose. So, you copy, customize, and then updates of >> > the distributed library are irrelevant: your project library has what >> > you need. >> >> We have a project library if you set one up in your gafrc, but that >> means you have another file required to open the schematic page and find >> the symbols, and that must be merged if you want to re-use a page in a >> different project. > > Not to mention that non-libgeda applications literally can't load your > schematic successfully, because they will not be able to determine where to > get the symbols from. > > My primary motive is to make it easy -- no, trivial -- to share schematics & > symbols with other users. > > My secondary motive is to make it easier for non-libgeda applications to > generate & manipulate gEDA-format schematics. > > When criticizing my approach, please take into account the following case > studies: > > > Case study 1 > ============ > > Peter is developing a new device using gEDA, and want to use an external > layout contractor (who also uses gEDA & PCB). Peter wants to package up his > schematic to send off to the contractor, but has several non-standard system > libraries as well as some project-specific symbols. > > Current model: Peter is an expert, so he is able to spend a few hours and use > some complicated shell scripts to hunt down every relevant symbol and > organize them into a new directory before manually checking through that the > correct symbols have been selected and that nothing has been broken. He then > tars the assemblage up before sending it to the contractor. The contractor > untars the files, and (if Peter was successful) can then use the schematic. > > Proposed model: Peter sends his schematic file to the contractor. The > contractor double-clicks on it, and it opens in gschem in fully editable and > consistent glory. > > > Case study 2 > ============ > > Peter is developing a new device using gEDA, and is looking for a symbol for > the LM7171 op-amp. Having found one on a random website, he wants to then > use it in his schematic. > > Current model: Peter hacks his gafrc to define a project-specific library, > places his new symbol in the appropriate location (double-checking that the > name doesn't conflict with an existing symbol), and then hunts through his > library list to locate it. > > Proposed model: Peter clicks the "From file..." button in his symbol > management window, selects the appropriate symbol file, and is prompted for a > symbol name. Accepting the default, the symbol appears in his list of active > symbols, and is automatically selected for placement. An icon next to its > list entry indicates that the symbol does not exist in any of the active > libraries, but because he only needs the symbol once in this particular > design, Peter doesn't worry about it. > > > Case study 3 > ============ > > Janet has been preparing a design using KTechLab, but finds that it lacks > some > functionality that he can get using gEDA. John decides that KTechLab needs a > gEDA schematic exporter. > > Current model: John's export filter has to generate project symbol > directories > and configuration files in addition to the actual schematics, and has to do > gymnastics to make sure no conflicts occur with existing files. > > Proposed model: John can just output schematic files with the necessary > symbols embedded, and knows that the schematics will Just Work even if there > are symbol naming conflicts with the user's existing gEDA libraries. > > > Case study 4 > ============ > > Having successfully completed a gEDA export filter, John decides to tackle a > gEDA import filter. > > Current model: John is screwed, because without converting KTechLab to use > the > the whole of libgeda + Guile interpreter, he can't find the symbols he needs. > > Proposed model: All the symbols can be found & used without any knowledge of > the libgeda library model whatsoever. > > > > I have more, but I'm sure you get the gist, and it's getting very late here. > > Peter > > [-- application/pgp-signature, encoding 7bit, 8 lines, name: signature.asc > --] > [-- Description: This is a digitally signed message part. --] > > [-- text/plain, encoding 7bit, charset: us-ascii, 7 lines --] > > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > -- Levente http://web.interware.hu/lekovacs _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user