Re: gEDA: xnf-gschem 20000416

[Ales Hvezda <ahvezda-at-NOSPAMseul_dot_org>]

Hi Steve Williams,

	I've been thinking about this e-mail for the past few days, going
over the various possibilities before I patch together a response.


>
>I've got a handful of library parts drawn, and they are starting to look
>decent. Here is a very early snapshot so that people can see where
>I'm going with this. The snapshot includes the XNF netlister, a directory
>with some symbols in it and some documentation in xnf-gschem.txt.


	Great!  A few nits/suggestions:

	In obuf-1.sym the device is a previously attached attribute that
was detached (it's detached and red), make it green or yellow.   Same for
inv-1.sym (but the device= is hidden so it doesn't really matter).  Same
for some of the other symbols.  I have tried to use red as an attention
getter in the symbols and gschem.

	Also when I setup my gschemrc to point to your symbols, the opad-1.sym
in the test.sch didn't line up correctly, but when I removed xunified from
my component-library it looked okay..  You may want to make sure that you
have the right component-library path's.

	After doing a quick glance, I didn't see any missing symbol 
attributes.  Looks good.


[snip]
>
>A REQUEST --
>
>Now, it looks like what I've done here need not be tightly coupled with
>gschem or gnetlist. For example, an .RPM can easily drop the files in
>place. It seems reasonable, therefore, to manage this stuff as a separate
>project. All that is missing is a way to add libraries without editing
>system-commonrc and all will be well. Perhaps system-commonrc can scan
>the sym/ directory and notice any directory it finds there as a library?


	Hmmmm..  That's fine with me to keep it's separate (after all it
is your code).  However, if it gets integrated it into gnetlist and the
standard symbol library, I will maintain the symbols and scheme code for
any major changes (such as format changes and/or attribute additions).
It's totally your call of course.

	As far as gschem and friends doing something "intelligent" about
searching for symbol libraries, eh, I'm slightly hesitant, because I
think that a tremendous strength of gschem/gnetlist and friends is that
component library search order and specification is highly regular,
ie, the user always knows which libraries are search first/last just
by looking in the rc file (if they know where to look for the rc files)
etc...  With something automatic, how is the search order of new libraries
defined?  Experience has taught me that no matter how clever I am, I'm
going to end up writing something "automatic" which screws up somebody
sooner or later. :-(  Now don't get me wrong, I'm not totally against
this, but I have to be careful with how I add something like this.

	What about a ./configure script which figures out where things
are installed, adds the appropriate lines to system-commonrc, and then
installs the stuff in the right place?	That way the user is still in
total control. :)  Writing this would be straightforward.  


>This last little bit makes it easy to completely install extensions by
>just dropping them in. This strikes me as an obviously valuable feature
>for very little cost.


	It's not a very difficult feature to add, but I wouldn't say
it comes at a particular low cost (at least not in terms of my coding
time :-| ), since I would now have to start traversing directories (I
need to specify a base directory, what if somebody wants multiple base
directories?), looking for unspecified dirs, determining if they are
symbol library directories, and then finally adding them "intelligently"
to the search order.  Hard no, implementation time consuming perhaps.
I know the implications of the words: "It will only take you 5 minutes to
add this feature" all to well.  Now what you meant by "cost" is probably
something completely different than what I came up with.  After all,
I look at everything through my implementation glasses. :)


>
>Please?
>


	I'll add this to the ever growing todo list once we
reach some sort of consensus, but there are things which have a much
higher priority (like undo and gnetlist documentation :-).

	Thanks for the work on the xnf netlister.

								-Ales