X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 2 Apr 2015 04:53:02 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] PCB and gschem libraries - bundling In-Reply-To: <201504011954.t31JsnKh020289@envy.delorie.com> Message-ID: References: <1427905808 DOT 32608 DOT 60 DOT camel AT benjamin-hp-g70> <20150401214846 DOT 5d2261e6 AT jive> <201504011954 DOT t31JsnKh020289 AT envy DOT delorie DOT com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 1 Apr 2015, DJ Delorie wrote: > > In order to get the most participation, I set the least number of > restrictions. It's a choice. If I had specified a rigid set of rules > and formats, we'd have fewer symbols available to us. > > What we need is a way to index those symbols, and a way for gschem/pcb > to read the indexes and use the files. > I agree. I maintain my own set of symbols and footprints in my svn repository (available for the public). I am sure there are other people doing the same, outside of the centralized cvs. Trying to enforce some centralized onely-one-good-way directory structure won't really work as a generic solution: more people will start using their own repos. I am against the database thing if it brings in new dependency for the tools (e.g. sqlite). As an alternative it's okay as long as it's totally decoupled, so there are external tools that handle the whatever database engine and the tools keep on using files on the local file system. At the end of the day, if an user doesn't want to use databases at all, there should be no dependency or any sort of complication for that user. Same generic preference goes for any sort of version control - keep it external, don't hardwire your favorite VCS into any of the tools. Bundling: I have an idea for gschem for bundling symbols without messing with the above consideration. There are embedded symbols already; we can embed and unembed already. A library could be a schematics that simply embeds a set of symbols. Most of the code is already there for this, and depending on what we want to use it for there is only a little part to add. I see two major use cases: 1. Use the bundle as a transport format: we only need a gschlas-like tool that can pack symbols from files into an sch by name and can unpack such a bundle into a set of directories/files in the current directory. This tool is as external as CVS or SVN or an sql dump/import tool, so it's just an alternative to pack up symbols. It's sort of a specialized tar (thus I am not sure we really need it). 2. Support the bundle natively in gschem: the symbol library can contain schematics that contain multiple symbols. In a sense such a bundle sch is a leaf subdir in the directory hierarchy. This would be reflected in the symbol selection dialog as well. While this would make grabbing/sharing such bundles easier, I find this risky, tho: introduces new corner cases, any indexing would required to understand and unpack bundles, making modifications to a symbol in a bundle is harder, etc. Since a PCB file embeds its footprints, the same boundling mechanism would work there too. Note: I had this idea during the previous discussion about how to clean up the default library, and how to make it easier to download and add new symbols into your local lib. Regards, Igor2