X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Db8XebBmy/81QvBq0ySbB8P99SMUiNZx7hWYIjznjfk=; b=SCis/GBIgCLqGxC/lkRV65mVNDJWyY02MSfMYTEoYDAhCpeT3aBkxrVoKCVJxg1doL WR5N7ijr41HjF+Uyr06DImJdqyDusGgQZbEUKQkZjLXITX51bVEt/l7wy7OChrLZFQxk f4vppk8R1gmsgDE4uc/zkzPHCnEv161MOv4h/4NPgMer1+yBOb2J4wepC+TFQr0PHc0d WOJR5hQn1FUwpvoAv6uV7nQsgggAJAC+lErexVI1eTHXtLuEWUbF08xnARfyKqpsXvnZ VBXQZ0qq4+Ub8PsZpnbh9S9UBXKLuZQ9NNW8eGvH+mmscEWU1x7rd072h9+ufi29XYnT dolg== MIME-Version: 1.0 In-Reply-To: <20130115013756.9917.qmail@stuge.se> References: <87wqvhd4tw DOT fsf AT gmail DOT com> <20130115013756 DOT 9917 DOT qmail AT stuge DOT se> Date: Mon, 14 Jan 2013 20:31:08 -0800 Message-ID: Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting a gEDA project From: Ouabache Designworks To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=f46d04083e3308962704d34c3b63 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 --f46d04083e3308962704d34c3b63 Content-Type: text/plain; charset=ISO-8859-1 Ben, While I like the idea of what you are trying to do I am afraid that your concept has a fundamental flaw in it. Every designer as well as every design organization has a place where they archive all their old projects. It is really handy when starting a new one to simply copy a working project , change the name and morph it into a new one. These archives contains all the IP that you have ever created or obtained and can be quite extensive. There are two different ways to organize IP in the archives. The traditional way that you follow is to organize based upon where the IP is used. The archives are full of old projects that are snapshots of the complete design environment used to build the design. The other way is to organize based upon where the IP was created. In this case the archives will consist of directories for each organization that created the IP and those directories contain all the IP created by that vendor. Your way worked fine 20-30 years ago when designs and design teams were smaller but it is really falling apart for today's stuff. If you had to reuse a piece from an old design project under your scheme it would take several attempts before you tracked down and found all the odd dependencies and brought those over. If you store everything by who created it then grabbing a sub-module becomes trivial. If you are working on a large project with several other designers then your scheme becomes difficult to manage and keep in sync. Under the other way each designer can work on their part in isolation and all the parts can then be joined in a larger project. There are some things that you could do to improve on what you are doing: 1) Keep your design IP separated from your tools and configuration data and stored by VLNV. VLNV is from Ip-Xact and stands for Vendor name , Library name , IP name and Version. It is designed to manage larger amounts of IP. Create a directory for all the IP. Under it you will have directories for gedasymbols.org,luciani.org,Bdales as well as your organization and any others that have created IP for your project. The vendor name should be a url that the vendor owns. That will prevent naming collisions when you start mixing in new ip. 2) Use lndir to create a workspace. Tool flows generate a ton of files. You do not want to create these files in a RCS repository because that will mean that you now need a way to clean out these files between runs and the repository has to be set up to ignore them so that the hand full of files that you are actually working on are easy to identify and won't get lost in the crowd. lndir clones an existing directory from a repository makes it out of symbolic links. You run all your toolflows in the cloned workspace and nothing is every generated into the repository. You never have to muck with the RCS ignore setups and clean is a simple rm -r and rerun lndir. Designs are getting larger and we need to start changing our design environments to better manage design reuse. John Eaton --f46d04083e3308962704d34c3b63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ben,

While I like the idea of what you are trying to do I am afr= aid that your concept has a fundamental flaw in it.

Every designer a= s well as every design organization has a place where they archive all thei= r old projects. It is really handy when starting a new one to simply copy a= working project , change the name and morph it into a new one. These archi= ves contains all the IP that you have ever created or obtained and can be q= uite extensive.

There are two different ways to organize IP in the archives. The tradit= ional way that you follow is to organize based upon where the IP is used. T= he archives are full of old projects that are snapshots of the complete des= ign environment used to build the design. The other way is to organize=A0 b= ased upon where the IP was created. In this case the archives will consist = of directories for each organization that created the IP and those director= ies contain all the IP created by that vendor.

Your way worked fine 20-30 years ago when designs and design teams were= smaller but it is really falling apart for today's stuff. If you had t= o reuse a piece from an old design project under your scheme it would take = several attempts before you tracked down and found all the odd dependencies= and brought those over. If you store everything by who created it then gra= bbing a sub-module becomes trivial. If you are working on a large project w= ith several other designers then your scheme becomes difficult to manage an= d keep in sync. Under the other way each designer can work on their part in= isolation and all the parts can then be joined in a larger project.

There are some things that you could do to improve on what you are doin= g:

1) Keep your design IP separated from your tools and configuratio= n data and stored by VLNV.

=A0=A0 VLNV is from Ip-Xact and stands fo= r Vendor name , Library name , IP name and Version. It is designed to manag= e larger amounts of IP.
=A0=A0 Create a directory for all the IP. Under it you will have directorie= s for gedasymbols.org,luciani.org,Bdales as well as your organization and an= y others that have created IP for your project. The vendor name should be a= url that the vendor owns. That will prevent naming collisions when you sta= rt mixing in new ip.

2) Use lndir to create a workspace.

=A0=A0 Tool flows generate a= ton of files. You do not want to create these files in a RCS repository be= cause that will mean that you now need a way to clean out these files betwe= en runs and the repository has to be set up to ignore them so that the hand= full of files that you are actually working on are easy to identify and wo= n't get lost in the crowd. lndir clones an existing directory from a re= pository makes it out of=A0 symbolic links. You run all your toolflows in t= he cloned workspace and nothing is every generated into the repository. You= never have to muck with the RCS ignore setups and clean is a simple rm -r = and rerun lndir.


Designs are getting larger and we need to start changing our design= environments to better manage design reuse.


John Eaton

<= br> --f46d04083e3308962704d34c3b63--