delorie.com/archives/browse.cgi | search |
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=x-received:from:to:subject:in-reply-to:references:user-agent:date | |
:message-id:mime-version:content-type; | |
bh=VQJRjdk0I4rA2gB3Dyxz9M+c4nUqqRrUK5Rx/c6LtpQ=; | |
b=c8a8SPKdlXZDSMGJq11M8AErrDVRIWQiD29Qk1UJlqUIlnTYufmIZWYScSXVkJ5m1t | |
Iq1n8rTHlWQjJ6FN19tLkAmEVI8Brp3epluxHO/2/WKFUWGtdJI1w58WONaCY4lcsJGo | |
r3vdg9wWcUZ08QjH0UUwApqNN4gJQD8IUJX5UQhHJNubmAolZw0fuU4IfBxPeflHpK5e | |
l+lDgq08nlXGp3d/gJHrDCY1UGN5J6wk7Xo2Q38ubI+WHZuPiFNIJLOhUzGFcXMbj/dN | |
5mx3HUAT0SgdC/gV9Df22bZqKlWro0z+ngQTpu13ew6qTtPsLBYKXJJaDK+TD+05dBKS | |
C2hw== | |
X-Received: | by 10.220.219.204 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: | <CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ@mail.gmail.com> |
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 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) |
Date: | Tue, 15 Jan 2013 10:37:06 -0500 |
Message-ID: | <87d2x6v4nx.fsf@gmail.com> |
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. Cheers, - Ben
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |