On Mon, 2007-11-12 at 17:31 -0500, Paul Tan wrote: Comments in line..
I appreciate your input, as its always good to keep track what features / methodologies the gEDA community values. > In small projects, embedding (as defined currently in gEDA) > may work well. However, for larger project, IMHO, it may > not work well at all. It may not be a fair analogy, > but just to illustrate a point: imagine, in a software > project, all functions are inline functions, ....., etc. > The gEDA gafrc's (component-library ..)s are similar to the > <xxxx.h>s, imagine if <xxxx.h>s are not used in a C/C++ > project... Peter B's suggestion to allow the option of embedding a named / referable single instance of some dependancy (symbol / graphic etc..) proposed to address this, but seemed to be met with some resistance to change from the current embedding scheme. It may have been that more opposition was felt to the output sorting / hashing of embedded data to make it more easily comparable to the main library. > (continue, by Peter Clifton) > >> I'm not sure... I wanted to make some changes anyway, bringing > >> net-listing more into libgeda rather than gnetlist. (gnetlist being a > >> command line exporter the existing guile backends, + libgeda to do > the > >> heavy lifting) > > I hope we all should study the issues of trying to bring "heavy lifting" > netlisting feature into libgeda, before doing it. I appreciate > your thoughts on this subject. One of the greatest strength > of gEDA is its built-in flexibility in accomodating all sorts > of diverse problems each netlister has to face. If we are not > careful, we might end up limiting gEDA as an excellent EDA > tools to support hobbist, students, PCB, SSI, LSI and multimillion > transistors VLSI design. A netlist isn't a particularly complex entity. Nor is the logic required to construct a page's worth of a netlist on the fly as libgeda's EDA database is running. This will allow gschem to track which components connect at runtime, and will be a big plus for interaction. I don't propose to hard-code all post-processing / output formats in libgeda, that would be wrong. I was proposing that the functionality construct a netlist data-structure from a schematic would be in libgeda, possibly with API functions for merging / manipulating that netlist, to be called by the output or "business logic" scripts. > I hope I don't sound unappreciative of all the good > works and excellent ideas you have contributed for gEDA, > my comment here only reflects my humble views on the subjects > which might affect gEDA's future. Some of us would be very > disappointed if gEDA ends up just like another educational > tools only. Perhaps I've been focusing too heavily towards educational tools. I personally use gEDA + PCB for designing power electronics and documenting systems. Sometimes this extends to simulation. The education "market" is an area where new users may meet various tools, so we shouldn't ignore it. Its also a market I get to see. I'm most interested to see potential barriers to entry and user adoption lowered / removed. If we don't have an active user + developer base, the project will suffer. I guess we just need to look at these integration challenges with an open mind, and try to see how it can be done "the gEDA way". It should be possible achieve most of these things without sacrificing the areas gEDA is strong in. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
