MIME-Version: 1.0
In-Reply-To: <20130115013756.9917.qmail@stuge.se>
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>
Date: Mon, 14 Jan 2013 20:31:08 -0800
Message-ID: <CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ@mail.gmail.com>
Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a
 starting a gEDA project
From: Ouabache Designworks <z3qmtr45 AT gmail DOT com>
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
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

<br>Ben,<br><br>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.<br><br>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.<br>
<br>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.<br>
<br>Your way worked fine 20-30 years ago when designs and design teams were=
 smaller but it is really falling apart for today&#39;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.<br>
<br>There are some things that you could do to improve on what you are doin=
g:<br><br>1) Keep your design IP separated from your tools and configuratio=
n data and stored by VLNV.<br><br>=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.<br>
=A0=A0 Create a directory for all the IP. Under it you will have directorie=
s for <a href=3D"http://gedasymbols.org">gedasymbols.org</a>,<a href=3D"htt=
p://luciani.org">luciani.org</a>,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.<br>
<br>2) Use lndir to create a workspace.<br><br>=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&#39;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.<br>
<br><br>Designs are getting larger and we need to start changing our design=
 environments to better manage design reuse.<br><br><br>John Eaton<br><br><=
br>

--f46d04083e3308962704d34c3b63--