Mail Archives: geda-user/2013/01/15/10:37:24

X-Authentication-Warning: 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;; s=20120113;
X-Received: by with SMTP id hv12mr103783002vcb.71.1358264229310;
Tue, 15 Jan 2013 07:37:09 -0800 (PST)
From: Ben Gamari <bgamari DOT foss AT gmail DOT com>
To: Ouabache Designworks <z3qmtr45 AT gmail DOT com>, geda-user AT delorie DOT com
Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting a gEDA project
In-Reply-To: <>
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>
User-Agent: Notmuch/0.14+240~g0ab5e9f ( Emacs/23.4.1 (x86_64-pc-linux-gnu)
Date: Tue, 15 Jan 2013 10:37:06 -0500
Message-ID: <>
MIME-Version: 1.0
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

Ouabache Designworks <z3qmtr45 AT gmail DOT com> writes:

> 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.
To be clear, I don't really view this project (if you can call it this)
as having much offer to engineers by profession. I'm certain that those
who have dozens of designs under their belt have by now established
their own work-flow which works well for them. In fact,
geda-skeleton-project is effectively a pared down copy of one of my
recent projects (save most of the footprints and symbols which I believe
should be kept in a separate repository).

My target audience here is not these people. Instead, I'm looking at
those who have the occasional need for a design. Personally, I'm a
graduate student in physics. My job is most certainly not to design
electronics. That being said, occasionally there is need for a small
project. Furthermore, I am a hobbyist who does a few small boards a year.
I have done just enough boards with gEDA to have developed a framework
but feel that the process of getting to this point was perhaps a bit
harder than it needed to be. A model project which an occassional gEDA
user can grab and quickly get up and running would have been extremely
valuable to me a few years ago. This is what I'm hoping
geda-skeleton-project will provide.

> 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.
The symbols and packages that remain in the repository are there simply
to serve as an example. I've considered removing them outright, which I
may still do.

> 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.
This is dealt with by .gitignore (which I provide with some sane
defaults) and git clean.


- Ben

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019