X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Authority-Analysis: v=2.0 cv=O9a7TWBW c=1 sm=0 a=6jktZp3dcHAl1vye2O6wCg==:17 a=jl9P3j1e7_0A:10 a=yqpquHFD9rMA:10 a=YW_e6Fk0WhoA:10 a=6WB07kdHjWAA:10 a=8nJEP1OIZ-IA:10 a=wR-FlJDvAAAA:8 a=py4ykTj1jEUA:10 a=lcUJnDsQAAAA:8 a=0S8s51K_AAAA:8 a=z-ZgcwS5iUPo6VzTklQA:9 a=wPNLvfGTeEIA:10 a=M3k38b3RpH0A:10 a=k73RJiQR_NQA:10 a=6jktZp3dcHAl1vye2O6wCg==:117
X-Cloudmark-Score: 0
X-Authenticated-User: 
X-Originating-IP: 70.113.67.117
Message-ID: <50F5853C.8060305@ecosensory.com>
Date: Tue, 15 Jan 2013 10:35:08 -0600
From: John Griessen <john AT ecosensory DOT com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting
 a gEDA project
References: <87wqvhd4tw DOT fsf AT gmail DOT com> <kd21ao$j6j$1 AT ger DOT gmane DOT org> <20130115013756 DOT 9917 DOT qmail AT stuge DOT se> <CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ AT mail DOT gmail DOT com> <50F4E4D1 DOT 3010802 AT ecosensory DOT com> <CAOP4iL1f=3TV5UKUjyJtpUw_5oBDxpk=5S2F=dEcUC2UYiNhVQ AT mail DOT gmail DOT com>
In-Reply-To: <CAOP4iL1f=3TV5UKUjyJtpUw_5oBDxpk=5S2F=dEcUC2UYiNhVQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

On 01/15/2013 12:05 AM, Ouabache Designworks wrote:
> When you move to the cloud then often the best way is to check out a tool repository into
> your design environment and run it from there. Then each design environment can choose its own tool versions.
>
> The challenge now is for tighter integration between IC and PCA databases. You cannot hand enter symbols any more. The design
> process that creates the IC should also create
> a BSDL file and this should be run through a script to create a symbol. Its faster and doesn't make spelling mistakes. Net list
> files for PCA design need to  go into system simulations

Glad to hear this kind of systematic suggestions here, since I come from chip design experience as well
as boards and see doing planar/stacked printed electronics with gEDA tools eventually -- hopefully soon.


I just happen to be learning to use chef to launch cloud instances on the web or on my LAN now too!
So, you got me thinking more broadly.


On 01/14/2013 11:35 PM, Peter Stuge wrote:> Let's back up a bit.
 >
 > What are the pros and cons of having a single IP library vs. having
 > different ones? (Both version controlled of course.)
 >
 > Are there any use cases for different (local) IP libraries? I can't
 > think of any.

Like John Eaton said sounds just the right way to me -- I'd describe it as
locally organized IP pool libraries.  The local organization could be
by symlinks, or don't worry about that detail and copy them to another
directory in the RCS meaning they are tested out in use, part of your trusted
library.  The naming of IP as from its creator and having a local RCS copy
like: "Under it you will have directories for gedasymbols.org,luciani.org,Bdales as well as your organization"
also sounds just right to me.  That lets you figure out the source when there is need for an update
and help your collaborators, so they will help you.  So, yes there are different local IP libraries
for categorizing, all under an IP RCS.  Another reason for local IP under RCS is in case
a source that is web published changes without a name change, you don't want to get caught
by that, or even be temporarily without source data, so you have your own mirror of it.

Then there is a design history RCS crammed with fab files
and confusing details of output as well as source files to keep locally.


John Griessen