X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Sun, 18 Oct 2015 22:32:06 -0400
Message-Id: <201510190232.t9J2W6XC008909@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <C040B148-8DCD-4CDC-A6F9-E0B92D349738@noqsi.com> (message from
	John Doty on Sun, 18 Oct 2015 16:49:31 -0600)
Subject: Re: [geda-user] Pin mapping (separate symbols from mappings)
References: <20151018204010 DOT 9cce6a231dcc296256e187bd AT gmail DOT com> <201510181843 DOT t9IIhmWo025346 AT envy DOT delorie DOT com> <20151018234424 DOT c0551dad9bef0859130239d9 AT gmail DOT com> <36B94694-F2AC-4A75-A8EB-40A1CE9A534C AT noqsi DOT com> <201510182225 DOT t9IMPkxK032763 AT envy DOT delorie DOT com> <C040B148-8DCD-4CDC-A6F9-E0B92D349738 AT noqsi DOT com>
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
Precedence: bulk


> >> In my opinion, geda-gaf must remain neutral with respect to the
> >> specifics of the downstream flow.
> > 
> > If we added a tool that sat between gschem and <downstream> that
> > "heavified" symbols, would that tool be part of geda-gaf and thus have
> > to be neutral about <downstream>, or would that tool not be, and thus
> > something geda-gaf would have to be neutral about?
> > 
> 
> A pcb-specific tool

I didn't mention pcb, or even layout, in my question.  "Heavy" symbols
are needed by most backends in some form or another, but what "heavy"
means tends to be backend-specific.

> A tool that adjusts BOM and connectivity data upstream of the
> gnetlist back end (and is therefore compatible with all of the back
> ends) would be a proper part of geda-gaf.

What if the backend needed more "history" than just what's in the
schematic?  For example, in layout (any layout, not just pcb) the
netlister might need to reference the as-built in order to know which
gates are still available for allocation and pin-mapping.

Such functionality would still be part of the netlister, but would
have to be backend-specific, since each backend has their own idea of
an "as-built".  How can a downstream-specific backend "remain neutral
with respect to the specifics of the downstream flow" ?  Where and how
do we decide between "this feature is part of geda-gaf" and "this
feature doesn't belong because it's too downstream-specific" even if
geda-gaf is the ideal place to implement that feature?

I'm not trying to be annoying here, I'm just thinking that heavy
symbols by definition are downstream-specific, we can't help but have
downstream-specific helpers (pin mapping, model choosing, whatever)
for the netlisters to use.  What does "neutral" mean for these
helpers?  That we can't have a helper unless at least two backends use
it, or that it has to be offered in a way that a backend can either
use it or not?