Mail Archives: geda-user/2015/10/18/22:32:29
> >> 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?
- Raw text -