Mail Archives: geda-user/2015/12/23/14:49:19
John Doty wrote:
> is it *really* so hard to write a parser for the .sch format?
It's harder than it needs to be for some tasks.
> Seems pretty trivial to me. Easier than figuring out what an
> extra layer is actually doing and wrapping it in yet another
> layer to support what *I* need.
I call bullshit here. You are making general comments about a
hypothetical piece of software. Let's save this discussion for
whenever there is something concrete.
Stephan Böttcher wrote:
> What I value most in both the gschem and pcb file formats is that
> they are easily AWK parsable, so that simple ad-hoc commandline
> scripts can cover deficiencies of the tools.
Sorry, but I think that's very poor practice, and I think we can do a
lot better.
The way that I see the file format thing playing out is most certainly
with an internal (*not* turing-complete) data format which is "owned"
by a C software library.
The library will hopefully have bindings in lots of different languages,
all your favorite languages, and I see the library being used directly
and indirectly through bindings both by GUI applications and a new
commandline tool which has several different plugins to output
various machine-readable formats on stdout - so that all existing
workflows not only continue to work, but have much easier access to
the data.
> For example, rigid-flex boards with more than two outer layers are
> handled with a little awk postprocessing of the pcb file before Gerber
> export. The awk code is embedded in the Makefile.
This is something that I think should be maintained within the gEDA
project rather than just within your Makefile. I actually want to
make a rigid-flex board too! :)
> This kind of ad-hoc scripting relies on the whitespace/newline
> placement that the tools write.
Having "relies on the whitespace" in your workflow is IMO a clear
sign that something is awfully wrong. :\
It's 2015 going on 2016 and we can do a whole lot better than that.
Don't worry, I'm not interesting in breaking any of your workflows,
I'm interesting in enhancing them with benefit for all.
> I have used gnumeric spreadsheets to generate pcb file fragments
> for complicated circular board outlines, hole and connector placements.
Then you could easily add a tool to this pipeline which takes an old
or new well-defined text format on stdin and outputs the native format.
> Emacs is regularly used to edit layout and schematics files, especially
> footprints.
I make all footprints by hand and think to myself what an utter waste
of time it is with every single one! :)
A dxf->fp converter would make sense, so that a decent CAD tool could
be used to draw footprints, as long as one stays with some simple rules.
//Peter
- Raw text -