Re: gEDA-user: Comments after successfully running gnetman . . . .

[Ales Hvezda <ahvezda@seul.org>]

[snip]
>I've been digging into this code a bit.  It's now clear to me we much 
>need to upgrade how symbols and schematics are found.

	I have no issues with this, just as long as the existing
scheme isn't broken.


>In particular, complex hierarchical designs often have multiple 
>schematics and symbols with the same name.  For example current chip, 

	same name in the same design I assume?  Yeah, gaf doesn't
like that much.

>having both a ROM and an SRAM, has two schematics and symbols named 
>"decode" as well as "bit" and "wldriver".  Also, I have no idea what 
>names will be used by the other designers.
>
>Therefore, both symbols and schematics need to be identified internally 
>by fully expanded path names (I'm using realpath to get this), rather 
>than the shorter base-name.  The source= attribute on symbols needs to 
>be a path name relative to the symbol.  If the schematic is not found 


	Okay, path relative to the symbol, but if a source= attribute
is attached to a component, then it can also be path relative to the
schematic. 


>with the relative path, then the name will be searched in the 
>source-library path.  The source= attribute on components will override 
>the source= attribute on symbols.  It needs to be a path name relative 
>to the schematic containing the component.  Again, if the schematic is 
>not found with the relative path, then the source-library will be searched.
>

	Fine. This shouldn't be hard to implement since all the path
searching and cache is contained withing libgeda/noweb/s_clib.nw and 
libgeda/noweb/s_slib.nw. 
						
								-Ales