Re: gEDA-user: net labels question

[Dan McMahill <dan@xxxxxxxxxxxx>]

Kai-Martin Knaak wrote:
> On Sun, 06 Apr 2008 18:10:00 -0400, al davis wrote:
> 
>> The real question:  Should gschem attempt to enforce naming conventions
>> of the various targets?
> 
> gnetlist is the component which is responsible for breakage in the 
> gschemm-gnetlist-pcb workflow. So gnetlist should is the application at 
> fault and should be made more robust against failure.

actually it is a result of abusing a private pcb interface.  I've ranted 
about this here before.

>> My opinion:  No, but the netlister should convert non-compliant names to
>> compliant names, and conversion back should restore the original name.
> 
> My opinion: Please don't resort to such syntax tricks behind the scenes. 
> Those schemes interact and fail in unexpected ways.  There is already 
> quite a bit of names munging in place. IIRC, the unfortunate hyphen-
> breakage of footprint names is already a consequence of non standard 
> string interpretation. 

I don't think there is any choice here unless you want to be incredibly 
limited in what gschem allows.  We have many different "standards" 
involved here.  I think your definition of standard means a string is 
just a string no matter what special characters are in it.  But here are 
some real limitations that we just have to deal with

- gsch2pcb doesn't like "-" in a footprint name.
- pads treats everything as uppercase
- switcap only allows 8 characters (unnamed_net14 is sunk already) and 
has a short list of allowed characters
- "spice" (in quotes since there are many variants) may or may not 
require the nodes to be numbered, may or may not allow things like "-" 
or "+" or "*" but may or may not take them when escaped.
- veriloga has certain keywords which may not be used as port names (q, 
v, etc are accessors)
- verilog, verilog-a, verilog-ams have keywords which can't be used as 
module names.

and I've only touched on a small subset of the backends.  In fact most 
of the backends for gnetlist drive tools which we have no control over. 
  So I think we're stuck with doing a translation.  I just don't see 
another way that keeps reasonable flexibility.  After all I don't think 
anyone really wants their namespace to be limited by the futurenet2 
backend...


-Dan


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user